On Wed, Aug 28, 2019 at 1:42 PM Matthew Woehlke via SG15 <
sg15_at_[hidden]> wrote:

> Okay... I'm going to take a step back here.
>
> First off, my understanding of Nathan's original post was as an attempt
> to establish what naming conventions we (SG15) plan to recommend. I also
> assumed this was intended to be part of the larger recommendations
> document we are working toward.
>
> Is this accurate? Does SG15 consider it important that sources exporting
> things have distinctive file names? Does SG15 consider it important to
> express an official opinion on what those conventions should be?
>
> If the answers are "no", then let's just stop, because I don't care what
> some communities recommend. I only care what *SG15/WG21* recommends.
>
> If the answers are "yes"... well, then, the question was raised *why* we
> need distinctive file names. So far, the answer I've seen to that (see
> Olga's messages) is "because VS".
>
> So, my questions are:
>
> - Are these implementation concerns peculiar to VS, or are they
> inherent, and thus likely to affect other tools and probably build
> systems as well?
>

Needing to know which file defines an importable interface is an inherent
issue with C++ modules.

VS may have other restrictions which are not inherent to C++ modules.


> - If they are inherent, what is their impact? It is hard to believe that
> only VS will have issues. Is there any other aspect of modules' design
> that should be reconsidered as a result?
>

The impact of needing to know which file defines an importable interface is
that you either need some metadata to identify them (separate index, file
extension, etc... (and look at the contents)), or you need to look at the
contents of all files. The impact of looking at the contents of a file for
most real C++ source is an open, a read of a single page, and application
of phases 1-4 of translation until you hit the first few preprocessing
tokens.

- If they are *not* inherent, do we (that is, SG15) nevertheless intend
> to prescribe naming conventions for the sake of one tool, which
> presumably could be altered to not need such conventions?
>

There are other reasons SG15 may want to prescribe naming conventions.
Additionally, if a widely used tool works a given way and its authors say
it is difficult to make it work a different way, it makes sense for the
tooling subgroup to produce a recommendation that works with the tooling
ecosystem.

- Michael Spencer

-- 
> Matthew
>