Am 04.05.2022 um 20:32 schrieb Daniel Ruoso via SG15:
> Em qua., 4 de mai. de 2022 às 13:17, Gabriel Dos Reis
> <gdr_at_[hidden]> escreveu:
>>> 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.
> Ok. The tension here is what we mean by "interface".
>
> From the tooling side, anything that needs to be visible is *a sort
> of* interface. In other words, from that perspective, when the module
> is consumed when parsing an unrelated translation unit, the "internal
> module partition" (to use your terminology) is part of the interface
> because tooling needs to be able to see it (as opposed to
> implementation units).
>
> From the language side, the interface is about the design of the code
> in question, in which case the "internal module partition" is not
> visible to the user.
>
> I can agree with this distinction.
>
> But it seems we are missing a term to describe the things that need to
> be visible when parsing a translation unit that imports a module
> (which includes "internal module partitions"), from the thing that
> don't need to be visible when parsing the translation unit, and will
> only be needed when the program is linked (module implementation
> units).

I'm not too happy with overloading the term 'visible' yet another time
beyond what the standard is already ascribing to it. Your description
above is what the standard is telling us in [module.reach] paragraphs 1
and 2. What you call 'visible' from the tooling perspective is the set
of TUs that are "necessarily reachable" from an importing TU because
they are part of the interface dependency graph. Therefore I'd like to
recommend to stick to existing terms in the standard when we are talking
about the same thing in tooling.

Your distinction is sound, though: there are TUs that are "necessarily
reachable" for parsing and there are object files which are required to
be available for linking.

Daniela

> There seems to have been some back-and-forth on this, and discussing
> here at C++Now with Michael, the term "importable module units" came
> up.
>
> So here's my revised attempt at terminology:
>
> 1. "Importable Module Units": Any translation unit that needs to be
> visible (presumably through binary module interface files) to 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. "Module Implementation Partition Units": The translation units
> with "module foo:bar"
>
> 2. "Non-importable Units"
>
> 2.1. Module implementation units: Translation units with "module foo;"
>
> 2.1. Non-modular translation units: Everything else
>
> daniel
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15

-- 
PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5