C++ Logo

sg15

Advanced search

Re: [SG15] module source suffixes

From: Nathan Sidwell <nathan_at_[hidden]>
Date: Thu, 29 Aug 2019 07:55:19 -0400
On 8/28/19 4:42 PM, Matthew Woehlke via SG15 wrote:
> Okay... I'm going to take a step back here.

Thank you!

> First off, my understanding of Nathan's original post was as an attempt
> to establish what naming conventions we (SG15) plan to recommend. I also
> assumed this was intended to be part of the larger recommendations
> document we are working toward.
>
> Is this accurate? Does SG15 consider it important that sources exporting
> things have distinctive file names? Does SG15 consider it important to
> express an official opinion on what those conventions should be?

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. I do not agree with that rationale.

I do understand that *users* might want to be able to locate the
interface files in a directory full of interfaces and other sources --
much like currently one can spot the header files as opposed to the
source files. Particularly if one wants to map the 1-header:1-source
idiom onto a 1-interface:1-implementation idiom.

In preparing a talk, I hit a usability problem with going the .cppm (or
whatever) route. I needed to teach GCC, Emacs and Make about the new
suffix. That's an impediment to doing the thing I wanted to do. It was
such an impediment that I looked for a way to avoid it!

Hence I went for a .m.cpp or -m.cpp approach, which avoided teaching
everything about the new suffix, and was simple & mnemonic in achieving
a distinguished name form.

That was the motivation for my question.

> If the answers are "no", then let's just stop, because I don't care what
> some communities recommend. I only care what *SG15/WG21* recommends.

I am fine with 'no'.

That the email thread went in the direction it did, suggests to me that
things are unclear. We should hesitate in recommending a change from
existing suffixes in that case.

nathan

-- 
Nathan Sidwell

Received on 2019-08-29 06:57:24