| -----Original Message-----
| From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Boris Kolpackov
| via SG15
| Sent: Monday, August 26, 2019 9:20 AM
| To: Nathan Sidwell via SG15 <sg15_at_[hidden]>
| Cc: Boris Kolpackov <boris_at_[hidden]>; Nathan Sidwell
| <nathan_at_[hidden]>
| Subject: Re: [SG15] module source suffixes
|
| 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/`).

Agreed.

|
|
| > 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.

I would suggest to keep things simple.

-- Gaby