Em qua., 4 de mai. de 2022 às 13:17, Gabriel Dos Reis
<gdr@microsoft.com> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15