Subject: [SG15] module source suffixes
From: Nathan Sidwell (nathan_at_[hidden])
Date: 2019-08-26 09:18:57
The proposals I've seen for a suffix to denote modular interface files
take the form of changing the traditional c++ suffixes to something else.
1) There's the discussion of whether the 'c' is replaced by an 'm', but
that leads to confusion if your suffix is '.cc' (hence the clang
approach of appending an 'm'.
2) It requires teaching all your tools (and users) that the new suffix
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.
These all seem somewhat awkward.
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?
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
-- Nathan Sidwell
SG15 list run by firstname.lastname@example.org