The SG15 discussion is going to be carefully scoped.

On Fri, Sep 20, 2019, 4:37 PM Michael Spencer via SG15 <
sg15_at_[hidden]> wrote:

> 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
>>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>