Date: Fri, 20 Sep 2019 14:38:56 -0400
On Fri, Sep 20, 2019 at 2:31 PM Boris Kolpackov via SG15 <
sg15_at_[hidden]> wrote:
> Gabriel Dos Reis via SG15 <sg15_at_[hidden]> 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.
>
> Agree.
>
> 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
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
sg15_at_[hidden]> wrote:
> Gabriel Dos Reis via SG15 <sg15_at_[hidden]> 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.
>
> Agree.
>
> 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
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
Received on 2019-09-20 13:41:16