* 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.
  *

Modules should reflect source code architecture, not a particular filesystem idiosyncrasies.

‘stat’ing the file system all the way is something we have 40+ painful experience with (‘#include); consuming an inode per module components (Perl’s way) is something we have 30+ years of painful experience with.

We should exercise caution with reflexively copying whatever we are familiar with. For familiarity may not necessarily be the answer to our problems.

-- Gaby

From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Daniel Ruoso via SG15
Sent: Friday, October 15, 2021 9:38 AM
To: iain_at_[hidden]
Cc: Daniel Ruoso <daniel_at_[hidden]>; sg15_at_[hidden]
Subject: Re: [SG15] P2473R0: Distributing C++ Module Libraries

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.