Date: Fri, 13 May 2022 13:23:24 +0000
[Daniel]
> Point of Consensus 1: We seem to generally agree with the broad
> categorization between "importable units" and "non-importable units".
> This is useful for tooling in general, since they give the main
> distinction on whether or not a bmi needs to be produced.
The standards define the notion of "importable units", and I have no quibble with that.
I would avoid introducing "non-importable units", especially if all that matters is that the implementation is able to produce a BMI for a construct. I wouldn't go as far as saying that the implementation being able to produce or non produce a BMI means that a translation unit is importable or non-importable. Success of producing the BMI may happen either because of intentional support or sheer happenstance.
> Point of Consensus 2: While we didn't discuss this in the thread, this
> seems to be a terminology we're using consistently, so it's worth
> settling on it. The terms "Named Module Units" and "Header Units"
> allow us to differentiate between the two kinds of importable units.
OK.
> Point of Consensus 3: "Primary Module Interface Unit" and "Module
> Interface Partition Unit" are terms that we don't seem to have any
> contention over.
OK.
> Point of Consensus 4: "Module implementation Units" is also a term
> that we don't seem to have any contention about.
OK.
> Point of Consensus 5: "Non-Modular Units" in order to refer to a
> translation unit that is not declaring or defining anything in a named
> module, although it may import modules.
Actually, I would rather avoid defining "module" that way. Maybe just "non module unit"?
Also, why do we need to define X and non-X at same time? Why can't we just specify what expect of X or can do with X and leave it at that?
> Open question 1: Is it useful to differentiate non-modular units that
> import other modules (header or named) from the ones that don't? If
> so, what terms do we want to use?
No. Primarily because I expect code in C++20 and beyond to be just mixture of '#include' and 'import' either lexically or through include translation.
> Open question 2: What do we call a "Module partition" which "does not
> contribute to the external interface"? We seem to have a contention
> between "Module Internal Partition Unit" and "Module Implementation
> Partition Unit".
My bias is towards what programmers do (or recommended to do) with those things as far as software construction is concerned; hence "internal".
-- Gaby
-----Original Message-----
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Daniel Ruoso via SG15
Sent: Wednesday, May 11, 2022 8:16 AM
To: sg15_at_[hidden]
Cc: Daniel Ruoso <daniel_at_[hidden]>
Subject: [SG15] Revisiting terminology, framing for meeting on 2022-05-13
Hello,
We are going to discuss this at the meeting on Friday, so I wanted to
get a summary of where we are on this discussion, what are the points
that we are closer to consensus on, and what are the open questions.
Hopefully this will make the conversation easier to drive.
Point of Consensus 1: We seem to generally agree with the broad
categorization between "importable units" and "non-importable units".
This is useful for tooling in general, since they give the main
distinction on whether or not a bmi needs to be produced.
Point of Consensus 2: While we didn't discuss this in the thread, this
seems to be a terminology we're using consistently, so it's worth
settling on it. The terms "Named Module Units" and "Header Units"
allow us to differentiate between the two kinds of importable units.
Point of Consensus 3: "Primary Module Interface Unit" and "Module
Interface Partition Unit" are terms that we don't seem to have any
contention over.
Point of Consensus 4: "Module implementation Units" is also a term
that we don't seem to have any contention about.
Point of Consensus 5: "Non-Modular Units" in order to refer to a
translation unit that is not declaring or defining anything in a named
module, although it may import modules.
Open question 1: Is it useful to differentiate non-modular units that
import other modules (header or named) from the ones that don't? If
so, what terms do we want to use?
Open question 2: What do we call a "Module partition" which "does not
contribute to the external interface"? We seem to have a contention
between "Module Internal Partition Unit" and "Module Implementation
Partition Unit".
Hope this helps,
daniel
_______________________________________________
SG15 mailing list
SG15_at_[hidden]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C4c5070002d8a4745c35208da33613c54%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637878789960015647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z0W2pE1z3xfDSjPpo5ej5VENPOKLqFrQaqAaiZKID14%3D&reserved=0
> Point of Consensus 1: We seem to generally agree with the broad
> categorization between "importable units" and "non-importable units".
> This is useful for tooling in general, since they give the main
> distinction on whether or not a bmi needs to be produced.
The standards define the notion of "importable units", and I have no quibble with that.
I would avoid introducing "non-importable units", especially if all that matters is that the implementation is able to produce a BMI for a construct. I wouldn't go as far as saying that the implementation being able to produce or non produce a BMI means that a translation unit is importable or non-importable. Success of producing the BMI may happen either because of intentional support or sheer happenstance.
> Point of Consensus 2: While we didn't discuss this in the thread, this
> seems to be a terminology we're using consistently, so it's worth
> settling on it. The terms "Named Module Units" and "Header Units"
> allow us to differentiate between the two kinds of importable units.
OK.
> Point of Consensus 3: "Primary Module Interface Unit" and "Module
> Interface Partition Unit" are terms that we don't seem to have any
> contention over.
OK.
> Point of Consensus 4: "Module implementation Units" is also a term
> that we don't seem to have any contention about.
OK.
> Point of Consensus 5: "Non-Modular Units" in order to refer to a
> translation unit that is not declaring or defining anything in a named
> module, although it may import modules.
Actually, I would rather avoid defining "module" that way. Maybe just "non module unit"?
Also, why do we need to define X and non-X at same time? Why can't we just specify what expect of X or can do with X and leave it at that?
> Open question 1: Is it useful to differentiate non-modular units that
> import other modules (header or named) from the ones that don't? If
> so, what terms do we want to use?
No. Primarily because I expect code in C++20 and beyond to be just mixture of '#include' and 'import' either lexically or through include translation.
> Open question 2: What do we call a "Module partition" which "does not
> contribute to the external interface"? We seem to have a contention
> between "Module Internal Partition Unit" and "Module Implementation
> Partition Unit".
My bias is towards what programmers do (or recommended to do) with those things as far as software construction is concerned; hence "internal".
-- Gaby
-----Original Message-----
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Daniel Ruoso via SG15
Sent: Wednesday, May 11, 2022 8:16 AM
To: sg15_at_[hidden]
Cc: Daniel Ruoso <daniel_at_[hidden]>
Subject: [SG15] Revisiting terminology, framing for meeting on 2022-05-13
Hello,
We are going to discuss this at the meeting on Friday, so I wanted to
get a summary of where we are on this discussion, what are the points
that we are closer to consensus on, and what are the open questions.
Hopefully this will make the conversation easier to drive.
Point of Consensus 1: We seem to generally agree with the broad
categorization between "importable units" and "non-importable units".
This is useful for tooling in general, since they give the main
distinction on whether or not a bmi needs to be produced.
Point of Consensus 2: While we didn't discuss this in the thread, this
seems to be a terminology we're using consistently, so it's worth
settling on it. The terms "Named Module Units" and "Header Units"
allow us to differentiate between the two kinds of importable units.
Point of Consensus 3: "Primary Module Interface Unit" and "Module
Interface Partition Unit" are terms that we don't seem to have any
contention over.
Point of Consensus 4: "Module implementation Units" is also a term
that we don't seem to have any contention about.
Point of Consensus 5: "Non-Modular Units" in order to refer to a
translation unit that is not declaring or defining anything in a named
module, although it may import modules.
Open question 1: Is it useful to differentiate non-modular units that
import other modules (header or named) from the ones that don't? If
so, what terms do we want to use?
Open question 2: What do we call a "Module partition" which "does not
contribute to the external interface"? We seem to have a contention
between "Module Internal Partition Unit" and "Module Implementation
Partition Unit".
Hope this helps,
daniel
_______________________________________________
SG15 mailing list
SG15_at_[hidden]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C4c5070002d8a4745c35208da33613c54%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637878789960015647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z0W2pE1z3xfDSjPpo5ej5VENPOKLqFrQaqAaiZKID14%3D&reserved=0
Received on 2022-05-13 13:23:27