C++ 20 Modules: submodules vs module partition difference

Question

I'm trying to learn the concept of modules that come with the C++20 feature. The concept of SubModule and ModulePartition confuses me a lot. They basically both do the same job, but I couldn't decide which one to use when and under what conditions.

Can you explain the difference to me exactly?

https://www.modernescpp.com/index.php/c-20-divide-modules

Answer 1

The difference between a "submodule" and a module partition is simple:

Submodules do not exist as a part of the module system. Module partitions are part of the module system.

A module partition is a component of a module which can be imported by other files that are themselves components of a module. This allows them to be used for private declarations that are used by multiple module implementation units, or for splitting a large module's interface into different files so that your single primary module interface unit isn't gigantic.

Partitions are effectively a way of namespace scoping a module. The partition X:Y can only ever be accessed by module units that are part of module X. The primary module interface of X may indeed export import a partition, but the outside world has no idea that those declarations are in the purview of a partition of X.

Within a module unit for the module X, you can import a partition Y of that module by naming it with :Y. That is, because the only partitions that a module unit for X has access to are the partitions of X, so there's no need to repeat yourself.

A "submodule" is not a part of a module system; it is a way of thinking about and treating a particular module. By convention, people use the naming convention X.Y to say that Y is a conceptual "submodule" of X. But this purely a convention; it has no syntactic legitimacy. That is, the language has no idea that the module X.Y has any inherent relationship to X (X could export import X.Y;, but there's no requirement to do so).

A module that is treated as a submodule is still, as far as the language is concerned, a full-fledged module with all of the powers and restrictions thereof. Its name has no special meaning, and you cannot make such a module "private" in any meaningful capacity.

Submodules (aka: just another module) does not "do the same job" as a proper partition at all. Submodules are exactly as visible to the outside world as the module that they are conceptually a "submodule" of.

The primary point of a module partition is that they are implementation details of a module. They're not something that leaks out into the module's interface. Submodules do. And maybe that's what you want.

But remember this: unlike headers, the cost of including a module is not based on how much stuff is in that module. So there isn't much point to breaking your library's interface into a bunch of tiny submodules(which is probably why the C++ committee is going to toss the entire standard library into a single std module instead of dozens of smaller modules). It's useful to have the interface defined in multiple files, but the outside world doesn't have to see them. How you choose to organize your code should be about your convenience, not how the user interacts with it.

Hence module partitions.

If what you want to do is provide multiple components of your library as different importable units, submodules are the tool for doing that. But if you're just organizing your code within a module and external code shouldn't need to know about that organization, that's what partitions are for.