[Dani]

  * Yeah, it's complicated(tm)

I posit it is complicated only when we insist that the current encryption in the standards text and its terminology faithful capture every aspect of the module design and its effective use as mechanism for software architecture. A compiler implementation view of the feature is unlikely to give us a simple clear picture of how programmers should use this functionality. From day-to-day programming perspective, we need to take a step back from the forest of the standards encryption. This is no new; we've done it for classes, and any other fundamental abstraction mechanism in the language. You see there the divide between implementers and users.

-- Gaby

From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Daniela Engert via SG15
Sent: Wednesday, May 4, 2022 7:23 AM
To: sg15_at_[hidden]
Cc: dani <dani_at_[hidden]>
Subject: Re: [SG15] P2581R0: Specifying the Interoperability of Binary Module Interface Files

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]><mailto: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(tm)

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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fslides.com%2Fdanielae%2Fa-short-tour-of-cplusplus-modules-meetingc%23%2F7&data=05%7C01%7Cgdr%40microsoft.com%7C3705bbefba5e48ce300a08da2dd9933f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637872709758585282%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=onQQ8s4F4hzyPKZ5Mh9NNOdf4XgHCuQwG0ni1apTgto%3D&reserved=0>

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]<mailto:SG15_at_[hidden]>

https://lists.isocpp.org/mailman/listinfo.cgi/sg15<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C3705bbefba5e48ce300a08da2dd9933f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637872709758585282%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZtCWqE04%2Foxvo%2FeC59MoGPTmj1uBQuH47yCk8vhC8%2FE%3D&reserved=0>

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