On Fri, Sep 20, 2019 at 11:26 AM Gabriel Dos Reis via SG15 <
sg15_at_[hidden]> wrote:

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

Thanks for this information Gaby. This helps clarify the apparent
contradiction. I'll update my paper to fix the purpose and add your
clarifications to Current Uses. I still feel that we need to discuss the
tradeoff we're making in SG2 and EWG, and the tooling uses in SG15.

- Michael Spencer


>
>
> *From:* SG15 <sg15-bounces_at_[hidden]> *On Behalf Of *Gabriel Dos
> Reis via SG15
> *Sent:* Friday, September 20, 2019 9:06 AM
> *To:* sg15_at_[hidden]
> *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]> *On Behalf Of *Michael
> Spencer via SG15
> *Sent:* Thursday, September 19, 2019 11:26 PM
> *To:* SG15 <sg15_at_[hidden]>
> *Cc:* Michael Spencer <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
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>