| -----Original Message-----
| From: tooling-bounces_at_open-std.org <tooling-bounces_at_open-std.org> On
| Behalf Of Scott Wardle
| Sent: Sunday, February 3, 2019 5:20 PM
| To: WG21 Tooling Study Group SG15 <tooling_at_open-std.org>
| Subject: [Tooling] SG15 Why do we need module name to file name mapping
|
| Hi all,
|
| I have been looking for some information why do we need a level of
| indirection from module name to module interface file name. Why are
| modules names need a different system then header names.

Both header files and module names have the same specification: that it is implementation-defined how an implementation does the mapping for the header file or module names to the actual source. In that respect there is nothing different. What I've seen is people insisting that the specification does something different for module names. I find such suggestion misguided.

What some of us, designers and implementers of C++ Modules, have been considering is how to inform implementation choices based on the lessons of 40+ years of usage of header files so that we avoid similar mistakes for modules, which are supposed to bring us in modern era with build characteristics very different from what was available back in the early '70 when #include was invented.

What follows is implementation strategy, not Standards specification.
Of course, having module names map directly to module interface source file names is the first thing that comes to mind. At least, based on reflexes acquired with the header files training. Then use a search methodology similar to header files search. That would work. But it will also just replicate a pain point we know is hurtful to build times. For a given header file, the compiler has to poke the filesystem repeatedly along a list of search directories. Most of the time, each poke is unsuccessful - it is very rare that the first directory on the list is the right one. No matter how fast your build setup filesystem is, those failures accumulate and count - especially with builds at scale.

So, instead of having the search fails repeatedly, the current module implementations have independently found that it is a better strategy to have the module napping upfront so that they do at most one filesystem poke per module. Such a mapping has to be explicit one way or the other -- even the GCC mapper server is explicit is some way. So, if you are going to have an explicit mapping (of some form) why restrict the mapping to be an identity function? There are various opportunities here. You could decide, after the build, to put all the binary module metadata in a single file. Or, embedded them in the .so/.dll so that it becomes self-descriptive. No body has to do that, but the point is that with an explicit map, opportunities occurs that we didn't consider before.

| I have hear that Microsoft was having some problems with name collision. Is
| there more concrete information about the problem that Microsoft or other
| companies were having?

I think you either misheard or what you heard was a misrepresentation.
Since day 1, MSVC's implementation of C++ Modules has the option "/module:search" to add search path, just like for include paths and use a search method similar to include files.
It is for convenience, not the recommended way for the reasons explained in the previous paragraph. MSCV recommends (for does not require) uses of direct mapping, mostly through the compiler option "/module:reference".

|
| If you have a name collision today with headers we would just make another
| library that wraps one of the two colliding headers. I name the public header
| of this new library something different and problem solved.
|
| So I don’t understand why are we paying for this level of indirection but I
| probably just don’t understand the problem.

See above.

-- Gaby