Date: Wed, 4 May 2022 16:22:50 +0200
Am 04.05.2022 um 15:47 schrieb Daniel Ruoso via SG15:
> 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.
Yeah, it's complicated™
This is a page from the slide-deck of my recent talks which lists the
various module TU types/pieces and their properties. Just to confuse the
audience:
https://slides.com/danielae/a-short-tour-of-cplusplus-modules-meetingc#/7
Not only header-units are special but also "the TU type colloquially
called 'module implementation partition'". See column 'contributes to BMI'.
Ciao
Dani
>> 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
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
> 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.
Yeah, it's complicated™
This is a page from the slide-deck of my recent talks which lists the
various module TU types/pieces and their properties. Just to confuse the
audience:
https://slides.com/danielae/a-short-tour-of-cplusplus-modules-meetingc#/7
Not only header-units are special but also "the TU type colloquially
called 'module implementation partition'". See column 'contributes to BMI'.
Ciao
Dani
>> 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
> _______________________________________________
> 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
Received on 2022-05-04 14:22:51