On Thu, Aug 29, 2019 at 3:15 PM Boris Kolpackov via SG15 <sg15@lists.isocpp.org> wrote:
Nathan Sidwell via SG15 <sg15@lists.isocpp.org> writes:

> My understanding is that SG15 was moving to recommend a different file
> suffix for CMI-producing source files.  I understood the rationale to be for
> tools.

The rationale was that it can be beneficial to know that a file is a
module interface unit from its name in various contexts (tools, humans,
etc), the same as we can do for headers.

I can see an argument for distinguishing importable units from non-importable units, but I'm not sure there is a reason for tools or humans to distinguish on the interface/implementation unit axis. Especially since implementation units *can* contribute to the interface of a module:

module foo:internal;
struct Args{int not_private;};

export module foo;
import :internal;
export void foo(Args);

import foo;
int main() { foo({.not_private = 1234}); }
After all, nothing prevents
one calling their headers .cpp (it is C++, right) but nobody does that
so there is clearly a benefit in the distinction.

Also, keep in mind that if the interface unit uses the same extension
as the implementation, then if you want to have both, you will have to
mangle one of them, for example:

foo.hpp  ->  foo.cpp
foo.cpp  ->  foo-impl.cpp

Another thing that just occurred to me is installation: do we want
/usr/include/ full of .cpp files?

I'm not sure we should recommend putting non-#include-able files in /usr/include. Importable module unit sources should probably get their own install directory. We may be able to recommend a convention where *installed* files are named based on the module+partition names, regardless of how the files are named in the original source repo. This would simplify the scanning situation of installed modules.

> We should hesitate in recommending a change from existing suffixes
> in that case.

I don't view this as changing something existing. Module interface
units did not exist until now. We are now deciding which extension
they should be using.
SG15 mailing list