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
>