On Wed, May 4, 2022 at 11:27 AM Gabriel Dos Reis via SG15 <sg15@lists.isocpp.org> wrote:
> In theory, yes, but names are important and sticky, so I wouldn't
> want to apply new names to the Working Draft without CWG and plenary
> consent.

While the current set of terms in the standards is not great, I would seriously caution against re-inventing the standards terminology from just tooling perspective.

First, we need to come up with the set of terminology for tooling; then see if those actually correspond to programmers practice of software construction; then see which subset of those term can be lifted into the C++ spec.

The upshot is that the needs for spec aren't exactly the same as those of tooling or the same as those of ordinary programmers.

-- Gaby

I actually think we can come up with terminology that makes sense for both. I think that the name "implementation partition" is particularly confusing to people. When Daniel and I were discussing this at C++Now we found meeting notes from 2018 where people were confused about them, and even today I keep seeing confusion around what they actually are.

Now, "implementation partition" doesn't actually occur in the standard, but an alternative name doesn't. People call them that because of the combination of 10.1/2 (A module interface unit is a module unit whose module-declaration starts with export-keyword; any other module unit is a module implementation unit.) and 10.1/3 (A module partition is a module unit whose module-declaration contains a module-partition). This wording makes sense when reading all of chapter 10, but is quite confusing when read alone.

A common misconception is that an implementation partition implements an interface partition like a .h/.cpp pair. Another misconception is that implementation partitions are just a way to split up an implementation, and don't need BMIs.

The truth is that module implementation units that are also module partitions are private interfaces. They define an interface that all translation units of the same module can use. You would never use an implementation partition if you did not want multiple other TUs to use it as an interface to some common types or functionality.

I'm not completely sure yet how I would want to rename things in the standard, but I do not believe we can continue to use and spread the current name of "implementation partition" without continuing the mass confusion.

- Michael Spencer

-----Original Message-----
From: SG15 <sg15-bounces@lists.isocpp.org> On Behalf Of Jens Maurer via SG15
Sent: Wednesday, May 4, 2022 9:26 AM
To: sg15@lists.isocpp.org
Cc: Jens Maurer <Jens.Maurer@gmx.net>
Subject: Re: [SG15] P2581R0: Specifying the Interoperability of Binary Module Interface Files

On 04/05/2022 17.30, Steve Downey via SG15 wrote:
> If we can figure out a better set of names, or improve consistency, without changing the semantics of modules, the draft could be fixed editorially. 

In theory, yes, but names are important and sticky, so I wouldn't
want to apply new names to the Working Draft without CWG and plenary

The scope here is a large-ish set of related names, likely needing
slightly involved fixes to the existing text.  It would be good
if those changes could be presented in a coherent paper for

Jens (co-editor)
SG15 mailing list
SG15 mailing list