Date: Fri, 15 Oct 2021 18:28:02 +0000
I would be extremely hard pressed to recommend practices that effectively shut down an evolution path where a given source file can have more than one module interface specification.
What we need is a mapping. This proposal suggests to encode that mapping into the host filesystem. I am skeptical that is the best practice to recommend in the context of C++.
-- Gaby
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Jayesh Badwaik via SG15
Sent: Friday, October 15, 2021 11:16 AM
To: sg15_at_[hidden]
Cc: Jayesh Badwaik <badwaik.jayesh_at_[hidden]>
Subject: Re: [SG15] P2473R0: Distributing C++ Module Libraries
More than confuse it will make future software engineering very hard, because if you have a lot of small modules which are then `import export`ed into a bigger module, people will come up with a naming scheme and I willing 5o bet that naming scheme would be a dot based naming scheme. And then standard module would the weird one which doesn't follow it.
This is a best case scenario. Worst case scenario would be that since standard doesn't have a naming scheme, there is no guidance and every organization will choose their own.
Any import line addition to source code will be it's own adventure in such a world.
On Fri, Oct 15, 2021, 20:12 Jayesh Badwaik <badwaik.jayesh_at_[hidden]<mailto:badwaik.jayesh_at_[hidden]>> wrote:
And this has a potential to confuse almost every single user of C++, where almost every is set of C++ users who are not in standard committee.
On Fri, Oct 15, 2021, 18:49 Steve Downey via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
The current leading contender for a std module that also has all of the C header global namespace exported is `std.compat`. We spent a lot of time because of the hierarchy implications and that std.compat is going to be larger than std.
The language doesn't imply for modules that '.' implies containment or hierarchy. It's just punctuation to separate identifiers which can allow other tools to disambiguate or lay things out somewhat sensibly on a filesystem, where '.' might map to a path separator.
On Fri, Oct 15, 2021 at 12:38 PM Daniel Ruoso via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
On Fri, Oct 15, 2021 at 12:22 PM Iain Sandoe <iain_at_[hidden]<mailto:iain_at_[hidden]>> wrote:
.. I had a question on the periods in module names (which might just mean I'm kinda new to the group and missed some previous design discussion)
These have no hierarchical significance to the compiler, what problem is it solving to make them have disk layout hierarchy in the tooling?
While it's true that they don't have hierarchical significance, the name is a list of identifiers separated by dots. The natural word separator for the file system is a hierarchy.
Now, apart from the strict reading of the standard, we have plenty of prior art in other languages for the translation of the word separator in the module name to the path separator in the file system, e.g.: Perl, Python, Java, Rust. Fortran doesn't seem to allow word separators in module names (haven't read the entire docs for it), and Golang uses an opaque string (intended as an URI, IIUC) as the identifier.
It also allows the filesystem usage to be smarter, instead of ending with a flat directory with all the module files in it.
_______________________________________________
SG15 mailing list
SG15_at_[hidden]<mailto:SG15_at_[hidden]>
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=04%7C01%7Cgdr%40microsoft.com%7Cf704ed40bee74375e00708d99007ed15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637699186010640932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ImCCp1LxZVtp%2FeCV4jig%2FJ%2FrefYghdhikA5F6GHoieI%3D&reserved=0>
_______________________________________________
SG15 mailing list
SG15_at_[hidden]<mailto:SG15_at_[hidden]>
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=04%7C01%7Cgdr%40microsoft.com%7Cf704ed40bee74375e00708d99007ed15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637699186010650928%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=n%2BL5xflPmv3jLeGV92to7MOfpRLPcpzE2WLjkb7nqvo%3D&reserved=0>
What we need is a mapping. This proposal suggests to encode that mapping into the host filesystem. I am skeptical that is the best practice to recommend in the context of C++.
-- Gaby
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Jayesh Badwaik via SG15
Sent: Friday, October 15, 2021 11:16 AM
To: sg15_at_[hidden]
Cc: Jayesh Badwaik <badwaik.jayesh_at_[hidden]>
Subject: Re: [SG15] P2473R0: Distributing C++ Module Libraries
More than confuse it will make future software engineering very hard, because if you have a lot of small modules which are then `import export`ed into a bigger module, people will come up with a naming scheme and I willing 5o bet that naming scheme would be a dot based naming scheme. And then standard module would the weird one which doesn't follow it.
This is a best case scenario. Worst case scenario would be that since standard doesn't have a naming scheme, there is no guidance and every organization will choose their own.
Any import line addition to source code will be it's own adventure in such a world.
On Fri, Oct 15, 2021, 20:12 Jayesh Badwaik <badwaik.jayesh_at_[hidden]<mailto:badwaik.jayesh_at_[hidden]>> wrote:
And this has a potential to confuse almost every single user of C++, where almost every is set of C++ users who are not in standard committee.
On Fri, Oct 15, 2021, 18:49 Steve Downey via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
The current leading contender for a std module that also has all of the C header global namespace exported is `std.compat`. We spent a lot of time because of the hierarchy implications and that std.compat is going to be larger than std.
The language doesn't imply for modules that '.' implies containment or hierarchy. It's just punctuation to separate identifiers which can allow other tools to disambiguate or lay things out somewhat sensibly on a filesystem, where '.' might map to a path separator.
On Fri, Oct 15, 2021 at 12:38 PM Daniel Ruoso via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
On Fri, Oct 15, 2021 at 12:22 PM Iain Sandoe <iain_at_[hidden]<mailto:iain_at_[hidden]>> wrote:
.. I had a question on the periods in module names (which might just mean I'm kinda new to the group and missed some previous design discussion)
These have no hierarchical significance to the compiler, what problem is it solving to make them have disk layout hierarchy in the tooling?
While it's true that they don't have hierarchical significance, the name is a list of identifiers separated by dots. The natural word separator for the file system is a hierarchy.
Now, apart from the strict reading of the standard, we have plenty of prior art in other languages for the translation of the word separator in the module name to the path separator in the file system, e.g.: Perl, Python, Java, Rust. Fortran doesn't seem to allow word separators in module names (haven't read the entire docs for it), and Golang uses an opaque string (intended as an URI, IIUC) as the identifier.
It also allows the filesystem usage to be smarter, instead of ending with a flat directory with all the module files in it.
_______________________________________________
SG15 mailing list
SG15_at_[hidden]<mailto:SG15_at_[hidden]>
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=04%7C01%7Cgdr%40microsoft.com%7Cf704ed40bee74375e00708d99007ed15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637699186010640932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ImCCp1LxZVtp%2FeCV4jig%2FJ%2FrefYghdhikA5F6GHoieI%3D&reserved=0>
_______________________________________________
SG15 mailing list
SG15_at_[hidden]<mailto:SG15_at_[hidden]>
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=04%7C01%7Cgdr%40microsoft.com%7Cf704ed40bee74375e00708d99007ed15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637699186010650928%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=n%2BL5xflPmv3jLeGV92to7MOfpRLPcpzE2WLjkb7nqvo%3D&reserved=0>
Received on 2021-10-15 13:28:06