[Daniel]
> I don't like the "internal partition" terminology

Something that does not contribute to the 'external' is 'internal', no?

> They are just plain "module partitions", it just so happens that there
> is a mechanism to control the visibility of that partition, which is
> the "export" keyword, but the use of the "export" keyword doesn't
> change what the module partition is in any significant way.

I don't agree. 'export' is not about visibility. It is about defining an interface. That notion is fundamental to the design of module.
The module design has no notion of 'internal' interface vs. 'external' interface'. There is just a notion of interface that consumers of a module depend on.
If you have an interface partition that is not re-exported by the primary interface, the program is ill-formed, no diagnostic required.

'export' isn't just a mere keyword.

-- Gaby

-----Original Message-----
From: Daniel Ruoso <daniel_at_ruoso.com>
Sent: Wednesday, May 4, 2022 6:48 AM
To: sg15_at_lists.isocpp.org
Cc: Iain Sandoe <iain_at_[hidden]>; Gabriel Dos Reis <gdr_at_microsoft.com>
Subject: Re: [SG15] P2581R0: Specifying the Interoperability of Binary Module Interface Files

Em qua., 4 de mai. de 2022 às 08:11, Gabriel Dos Reis via SG15
<sg15_at_[hidden]> escreveu:
> Yes, understandable. One snag with that conversion is that we similarly end up with
> "interface partition" - which, I believe is a common term these days.

The terms used by the standard are:

 * "Primary Module Interface Unit"
 * "Module partition" which is "module interface unit forming part of
the interface"
 * "Module partition" which "does not contribute to the external interface"
 * "Module implementation Unit"

The keyword here is "external interface". Every module partition
contributes to the module interface, because it can be imported, even
if not re-exported, by the primary module (or by other partitions).

The distinction between the two types of partitions is just that the
"Primary Module Interface Unit" and the "Module Partition" have to
agree with the exportability of that part of the interface. But even
the module partitions that are not exported still contribute to the
module's interface (just not its "exported" interface).

For that reason, I don't like the "internal partition" terminology,
because it makes it sound like it's not required to be seen by the
consumers of a module, which is not true. I, personally, would try to
avoid making a fundamental distinction between module partitions that
can be exported versus not the ones that can't.

They are just plain "module partitions", it just so happens that there
is a mechanism to control the visibility of that partition, which is
the "export" keyword, but the use of the "export" keyword doesn't
change what the module partition is in any significant way.

> The next question
> that programmers (not WG21 experts) ask is: "oh so, an implementation partition
> implements the interface partition, just like .h/.cpp files common practice?"
> The answer is "no". And they get thoroughly confused.

This is, I agree, unfortunate. The asymmetry that interfaces have
partitions but the implementations don't will definitely be confusing.
But it is what is in the language.

> Hence, the term "internal partition" used by MSVC in its documentation
> and education materials.

I have to disagree there, tho. I think "internal partition" is even
more confusing, imho. Because it creates a conceptual distinction that
I don't think exists.

I think it'll be clearer to make a distinction at a higher level, essentially:

 1) Module interface has a "primary unit" and it can have
"partitions". Partitions can contribute to the exported interface or
not.

 2) Module implementation units provide any required definitions from
the declarations in the module interface (primary unit or partitions).

daniel