We discussed this on the tooling telecon today. Here are the minutes:

Please review and notify us if anything needs to be corrected.

The final copy of these minutes will be in P1687R2

Attendees:
Ben Craig
Bryce Lelbach
Bruno Lopes
Steve Downey
Michael Spencer
Olga Arkhipova
Mark Zeren

Spencer: Will have paper on modules dependency discovery for denver meeting
   import at the start of a line anywhere means a module import
   can't find module declarations without full preprocessing
   Lots of issues with global module fragment vs. no global module fragment

>From Bryce Lelbach to Everyone: 11:06 AM
https://isocpp.org/files/papers/P1845R0.html

Olga: Won't have anything in time for Denver, but will for Belfast
Downey: Won't have anything for Denver
Bruno: May write something on build modes, maybe for Denver

Ben Q1: What kinds of decisions would your tools like to make based
off of extension?
Ben Q2: What tools become would become more difficult to use if we add
extensions to the ecosystem? What are the failure modes and
mitigations?


Downey:
Extensions cause some internal panic. Want to be able to disambiguate
things. Already have foo.h and foo.cpp, have a third thing to name.
Won't be able to cut over instantaneously. Still compiling the same
sources in 98, 14, and 17. Would be nice if we didn't need to get too
inventive about it.

Olga:
The extension would be helpful to determine what outputs a file should
produce. A regular .cpp could produce just an .obj, some other
extensions could cause an .obj and a .bmi to be produced. These could
be made explicit, but it's nice if the build system can guess based
off of the extension. If we use file name suffixes, there's a good
chance that the file suffix would cause name collisions (e.g. foo.cpp
and foo_impl.cpp already exist, an implementation module in foo.cpp
would collide with the already existing foo_impl.cpp.

Bryce:
concern on mailing list about scanning performance.

Bryce:
Is the cost greater if we have lots of extensions? Do we lower the
cost if we rally behind one extension? Is it enough where we really
want to encourage just one?

Olga:
Not sure if one or many will make a big difference for the tools that
need to adapt. It would be helpful to reduce the confusion.

Bryce:
Within some boost-like libraries, some files use the extension .ixx.
This isn't a very common extension, but very little tooling recognizes
it.

Bryce:
Is a new extension necessary for fast dependency scanning? Any idea
on what the cost is for scanning all the .cpps vs. just the ones with
the extension?

Spencer:
Pretty low cost. Does depend on file system cost and whether you are
on an NFS. You can figure out if it is a module with just a one page
read. For the files that are modules, you still need to look at those
more. There's a cost, but it's small (although file dependent).

Downey:
You have to open up all the other files to figure out what they are
depending on.

Spencer:
Where it matters most, I open up my IDE, I don't have a prebuilt
index. I open a file, I do the code completion shortcut, how long
will it take to get results? For that, we only need to look at the
current file and its dependencies. For built systems, I don't think
it really helps except when you are trying to glob things.

Olga:
Opening file performance is an issue for solution load performance.
Just getting file case was 10-15% of solution load.

Spencer:
If you take the stance that all TUs need a .cpp or .cc extension and
.h is not a TU, then you will have naming issues when you turn your
foo.h / foo.cc pair into module interface + module implementation.

Downey:
If you are turning foo.cc -> foo.o and you are also turning foo.ccm ->
foo.o, you have a problem

Olga:
Would be nice if it generated foo.cc.o instead of foo.o.

Downey:
CMake does this.

Bryce:
What about partitions?

Ben + Spencer:
If you have extensions for interfaces, then you need the same
extensions for partitions implementations and partition interfaces
because they have the same set of tooling properties.
(seems to be echoes in some reflector emails)

Spencer:
As a user, you want to be able to navigate your code. Makes sense
that you would have a naming scheme that will tell you which module or
which partition it is in.

Bryce:
Consensus is that we don't want to prescribe a scheme.

Spencer:
It is helpful to have an extension if opens are expensive, but it
doesn't help tooling to distinguish between partitions and interfaces

Downey:
The TR isn't going to recommend file name conventions, but your org
probably should have some convention. Tooling won't need it, but
people probably will.

Bryce:
If I have one module in my project, I may not want to embed that
module name into every partition in my project.

Downey:
But if you have 10s of them, you probably do. This isn't a concern
for the TR, but a usability thing that can be developed locally.

Olga:
If people will figure things out anyway, then we can give something as
a sample, but we don't need to give a recommendation

Spencer:
You may have something like a module name corresponds to a directory,
but the partitions are files, so you don't duplicate the names.

Bryce:
Might want to recommend that people have a scheme, without picking one.

Spencer:
Not sure if that would be helpful.

Spencer:
Build2 automatically assumes some structure for your project.

Downey:
Evoke is also opinionated on project structure.

-- 
Bryce Adelstein Lelbach aka wash
CUDA Core C++ Libraries Lead @ NVIDIA
ISO C++ Library Evolution Incubator Chair
ISO C++ Tooling Chair
CppCon and C++Now Program Chair
CUDA Convert and Reformed AVX Junkie
Sleep is for the weak
--