C++ Logo


Advanced search

Re: P2581R0: Specifying the Interoperability of Binary Module Interface Files

From: Iain Sandoe <iain_at_[hidden]>
Date: Fri, 6 May 2022 20:41:32 +0100
> 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

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.


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

Received on 2022-05-06 19:41:35