Date: Fri, 20 Sep 2019 18:50:10 +0000
* 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.
Correct, that is deliberate.
* With a.b, the a module and other submodules of a are unable to forward declare types owned by a.b, and vice-versa.
Again, correct and deliberate. A.b. is a module distinct from any other module.
* With a:b, forward declaration is legal for all entities owned by the a module.
Agreed.
* 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.
There is no ‘a.b’-submodule. If you want ability to import module partitions, then that is a separate discussion to have.
If you want ‘another’ notion of submodule, very distinct from ‘module partitions’, then please let’s see and discuss that proposal on its merit.
One thing that has come up consistently during presentations to programmers is that the idea of ‘submodules’ that would be distinct from module partitions is at best tenuously supported by concrete practical scenarios at large.
At any rate, at this point we have at best a nebulous idea of hypothetical submodule, but we are dead certain that its semantics require the dots in names? I don’t think that is a reasonable design and evolution strategy.
-- Gaby
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Mathias Stearn via SG15
Sent: Friday, September 20, 2019 11:39 AM
To: sg15_at_[hidden]
Cc: Mathias Stearn <redbeard0531+isocpp_at_[hidden]>
Subject: Re: [SG15] Paper for Saturday CppCon Tooling meeting: remove.dots.in.module.names
On Fri, Sep 20, 2019 at 2:31 PM Boris Kolpackov via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
Gabriel Dos Reis via SG15 <sg15_at_[hidden]<mailto: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]<mailto:SG15_at_lists.isocpp.org>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=02%7C01%7Cgdr%40microsoft.com%7Cf36bddbc157f4d1be36108d73df9d46b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637046015533649355&sdata=6O0O1zOUCdY3amUrqHuBGWp44rFwMypDQfgAntwTz4I%3D&reserved=0>
Correct, that is deliberate.
* With a.b, the a module and other submodules of a are unable to forward declare types owned by a.b, and vice-versa.
Again, correct and deliberate. A.b. is a module distinct from any other module.
* With a:b, forward declaration is legal for all entities owned by the a module.
Agreed.
* 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.
There is no ‘a.b’-submodule. If you want ability to import module partitions, then that is a separate discussion to have.
If you want ‘another’ notion of submodule, very distinct from ‘module partitions’, then please let’s see and discuss that proposal on its merit.
One thing that has come up consistently during presentations to programmers is that the idea of ‘submodules’ that would be distinct from module partitions is at best tenuously supported by concrete practical scenarios at large.
At any rate, at this point we have at best a nebulous idea of hypothetical submodule, but we are dead certain that its semantics require the dots in names? I don’t think that is a reasonable design and evolution strategy.
-- Gaby
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Mathias Stearn via SG15
Sent: Friday, September 20, 2019 11:39 AM
To: sg15_at_[hidden]
Cc: Mathias Stearn <redbeard0531+isocpp_at_[hidden]>
Subject: Re: [SG15] Paper for Saturday CppCon Tooling meeting: remove.dots.in.module.names
On Fri, Sep 20, 2019 at 2:31 PM Boris Kolpackov via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
Gabriel Dos Reis via SG15 <sg15_at_[hidden]<mailto: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]<mailto:SG15_at_lists.isocpp.org>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=02%7C01%7Cgdr%40microsoft.com%7Cf36bddbc157f4d1be36108d73df9d46b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637046015533649355&sdata=6O0O1zOUCdY3amUrqHuBGWp44rFwMypDQfgAntwTz4I%3D&reserved=0>
Received on 2019-09-20 13:52:19