C++ Logo

SG15

Advanced search

Subject: Re: P2473R0: Distributing C++ Module Libraries
From: Jayesh Badwaik (badwaik.jayesh_at_[hidden])
Date: 2021-10-15 13:16:10


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]> 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]>
> 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]> wrote:
>>
>>> On Fri, Oct 15, 2021 at 12:22 PM Iain Sandoe <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]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>>>
>> _______________________________________________
>> SG15 mailing list
>> SG15_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>>
>



SG15 list run by sg15-owner@lists.isocpp.org

Older archives