I’d like to better understand the reasons why people find new file extension for module interface sources problematic/undesirable. Can somebody describe some scenarios where new extension will cause problems while having modules with old extension will not?

For opening a file and reading a few lines: if it definitely good that we don’t have to parse all file content, but just opening a file takes way more time than checking an extension (or suffix). Again, this is not an issue if you deal with one or a few files. But if you need to do this for all files in a big codebase, it will definitely be a problem.

Thanks,
Olga


From: Michael Spencer <bigcheesegs_at_[hidden]m>
Sent: Wednesday, August 28, 2019 2:55 PM
To: sg15_at_lists.isocpp.org
Cc: Gabriel Dos Reis <gdr_at_[hidden]>; Olga Arkhipova <olgaark_at_[hidden]>; Matthew Woehlke <mwoehlke.floss_at_[hidden]>
Subject: Re: [SG15] module source suffixes

On Wed, Aug 28, 2019 at 1:42 PM Matthew Woehlke via SG15 <sg15_at_[hidden]<mailto: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