Date: Fri, 15 Oct 2021 20:12:53 +0200
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
>
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
>
Received on 2021-10-15 13:13:06