I received a private request to expand on this, since P0142 (http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0142r0.pdf) appears to contradict that statement. So, let me explain.

What P0142 called ‘submodules’ is roughly (except a couple of things) what we have today as ‘module partitions’. In that paper, I stated:

The one distinctive property of a submodule is that its name is only accessible to modules that have access to its parent, provided it is explicitly exported by the parent module.
A submodule can serve as cluster of translation units sharing implementation-detail information (within a module) that is not meant to be accessible to outside consumers of the parent module.

That was the principal desired semantics. The module partitions we have today handle are a good approximation, except we don’t export the partition part of a partition name and I think that is fine.

By the time we got the Merged Modules, we have had enough internal use and experience to let me believe we should retain that notation, even when we got a different notation for module partitions. Reserving that notation for submodules only would have been a design mistake in the sense that it supposes such hierarchical organization is more prevalent than a higher level organization that is not enforceable at the language level. For example, thinking that submodules XYZ.* will all form a coherent unit can be imported as a whole in a given program is a nice theory but too naïve to be the case in practice for any medium to large organization XYZ. Rather, what happens is that the hierarchical naming X.Y.Z follows higher level patterns (sometimes organizational) that is not expressible in the language and that is fine. In fact, such organization are more prevalent that the strict submodules envisioned in the historical recount.

The upshot of this is that retaining the dot in module names is NOT a mistake, and not in support of hypothetical submodules – we did have a good approximation of the submodules that I envisioned in P0142 (and its previous revisions).

A long time ago, I considered the mapping x.y.z for a hypothetical mapping to filesystem x/y/z (and that was suggested a few times) and concluded that it would be a mandated waste of inodes (or equivalents), clearly not scalable to the environments where C++ is used.


In conclusion, I do not consider that we have a bug or a mistake to fix by removing dots in module names.

If we have specific problems that we believe tools can help with, let’s discuss that.

-- Gaby


From: SG15 <sg15-bounces_at_lists.isocpp.org> On Behalf Of Gabriel Dos Reis via SG15
Sent: Friday, September 20, 2019 9:06 AM
To: sg15_at_[hidden]p.org
Cc: Gabriel Dos Reis <gdr_at_[hidden]>
Subject: Re: [SG15] Paper for Saturday CppCon Tooling meeting: remove.dots.in.module.names

Michael –

The premise of the paper


  * .s in module names exist in support of submodules

Is not factually correct. I didn’t introduce that convention in support of ‘submodules’.

-- Gaby

From: SG15 <sg15-bounces_at_[hidden]<mailto:sg15-bounces_at_[hidden]>> On Behalf Of Michael Spencer via SG15
Sent: Thursday, September 19, 2019 11:26 PM
To: SG15 <sg15_at_[hidden]<mailto:sg15_at_lists.isocpp.org>>
Cc: Michael Spencer <bigcheesegs_at_[hidden]m<mailto:bigcheesegs_at_[hidden]>>
Subject: [SG15] Paper for Saturday CppCon Tooling meeting: remove.dots.in.module.names

At the request of the Tooling subgroup chair, I've attached D1873r0.0 (remove.dots.in.module.names). I'd like to discuss the Tooling relevant parts of it on Saturday.

I would like to restrict this discussion to how tooling is intending to make use of `.` in module names (section 2 of the paper), as the rest of the paper is outside the scope of the Tooling subgroup and this is a very late paper.

- Michael Spencer