On Fri, Sep 20, 2019 at 2:31 PM Boris Kolpackov via SG15 <sg15@lists.isocpp.org> wrote:
Gabriel Dos Reis via SG15 <sg15@lists.isocpp.org> writes:

> By the time we got the Merged Modules, we have had enough internal use and
> experience to let me believe we should retain that notation, even when we
> got a different notation for module partitions.  Reserving that notation for
> submodules only would have been a design mistake in the sense that it
> supposes such hierarchical organization is more prevalent than a higher
> level organization that is not enforceable at the language level.  For
> example, thinking that submodules XYZ.* will all form a coherent unit can be
> imported as a whole in a given program is a nice theory but too naïve to be
> the case in practice for any medium to large organization XYZ.  Rather, what
> happens is that the hierarchical naming X.Y.Z follows higher level patterns
> (sometimes organizational) that is not expressible in the language and that
> is fine.  In fact, such organization are more prevalent that the strict
> submodules envisioned in the historical recount.


The way I think of this, interface partitions are "module-private"
submodules (i.e., a user of a module cannot import individual partitions).
But the author of a module may wish to (but does not have to) organize
their modules into publicly-visible submodules.

But the current semantics of the syntax a.b differs from a:b in more ways than just whether the submodule is publicly importable or not. With a.b, the a module and other submodules of a are unable to forward declare types owned by a.b, and vice-versa. With a:b, forward declaration is legal for all entities owned by the a module. Additionally, a:b-submodules have access to each others module-linkage entities, while a.b-submodules do not. We do not have a real publicly visible equivalent to partitions.
SG15 mailing list