Nathan Sidwell via SG15 <sg15_at_[hidden]> writes:

> 2) It requires teaching all your tools (and users) that the new suffix means
> C++.

There was a pretty strong consensus that module interface units are
sufficiently distinct to need a separate extension. There was no
consensus on which one, though.


> 3) With a paired header file/source file source base of the form foo/foo.cc
> or foo.h/foo.cc, converting the header to an interface will require either
> renaming the stem of one of them, or teaching the build system that naming
> the object file from the stem is not right.

Build systems that know how to build both static and shared libraries at
the same time already know that. So this is just another object type.


> There's also the issue of module partitions. IIUC the new suffix is to
> denote interfaceness. But module partitions also fall into the same boat as
> primary module interfaces in that regard -- they generate CMIs. Naming
> module partitions with the same suffix as primary interfaces seems
> confusing. What's been discussed about that?

I've been thinking about that and came to the conclusion that implementation
partitions are just module-private interface partitions. It therefore makes
sense to use the same suffix. In a sense, it's the same problem as public vs
private headers; some like to distiguish them by where they are placed (i.e.,
`include/` vs `src/`).


> Has there been discussion of naming the module interface by prepending a new
> suffix: foo.m.cc (or foo-m.cc) This avoids the above 3 issues. multisuffix
> files do exist (foo.tar.gz), but perhaps the '-m' form may be more
> palatable?
>
> Further, one could use 'mp' to denote a module partition:
> foo-m.cc -- primary interface
> foo-mp.cc -- partition
> foo.cc -- implementation

An immediate problem that I see is `foo-m.cc` vs `foo_m.cc` vs `FooM.cc`;
that is, whatever we choose, it won't fit 3/4 of the naming schemes out
there.

I think the best we can hope is to agree that codebases should use a
distinct suffix for module interfaces. Anything else is bound to clash
with widely-used naming schemes.