> On 6 May 2022, at 19:55, Daniel Ruoso via SG15 <sg15_at_[hidden]> wrote:
>
> Em qui., 5 de mai. de 2022 às 13:08, Michael Spencer via SG15
> <sg15_at_[hidden]> escreveu:
>> I actually think we can come up with terminology that makes sense for both.
>
> I think MSVC may actually have come up with the right name already in
> the /internalPartition option.
>
> The standard doesn't give a name for it but it says it "doesn't
> contribute to the external interface". So we could just take it as the
> opposite of "external" and call it "Internal Module Partition Unit".
>
> So here it is revised once again:
>
> 1. "Importable Module Units": Any translation unit that needs to be
> reachable (presumably through binary module interface files) for the
> parsing of a different translation unit.
>
> 1.1. "Primary Module Interface Unit": The translation unit with
> "export module foo;".
>
> 1.2. "Module Interface Partition Units": The translation units with
> "export module foo:baz"
>
> 1.3. "Internal Module Partition Units": The translation units
> with "module foo:bar"

.. IMHO the last iteration was closer.
The standard clearly says these are implementation units, it does not mention
‘internal’ AFAICS. They contain a partition, therefore ‘partition implementation’
 (or the reverse word order, if that’s concensus) seems reasonable.

> 1.4. "Header Units": Headers as seen when imported.
>
> 2. "Non-importable Units": Translation units that do not influence
> the parsing of other translation units.
>
> 2.1. Module implementation units: Translation units with "module foo;"

.. by the same token, we are not going to call these 'internal module
implementation units” because they have no export keyword.

> 2.2. Non-modular translation units: Everything else

Another thing that I think would be helpful is to sketch out a non-trivial
module (i.e with multiple partitions and at least one that is implementation)
and then describe the source code TUs that would contribute to such a
project..

e.g. if there is code that the module-vendor does not wish to
distribute, there might be private APIs that the module vendor does not
even wish to be visible to the consumer of the module.

Iain

>
>
> daniel
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15