Date: Wed, 4 May 2022 17:27:03 +0000
[Jens]
> In theory, yes, but names are important and sticky, so I wouldn't
> want to apply new names to the Working Draft without CWG and plenary
> consent.
Agreed.
While the current set of terms in the standards is not great, I would seriously caution against re-inventing the standards terminology from just tooling perspective.
First, we need to come up with the set of terminology for tooling; then see if those actually correspond to programmers practice of software construction; then see which subset of those term can be lifted into the C++ spec.
The upshot is that the needs for spec aren't exactly the same as those of tooling or the same as those of ordinary programmers.
-- Gaby
-----Original Message-----
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Jens Maurer via SG15
Sent: Wednesday, May 4, 2022 9:26 AM
To: sg15_at_[hidden]
Cc: Jens Maurer <Jens.Maurer_at_[hidden]>
Subject: Re: [SG15] P2581R0: Specifying the Interoperability of Binary Module Interface Files
On 04/05/2022 17.30, Steve Downey via SG15 wrote:
> If we can figure out a better set of names, or improve consistency, without changing the semantics of modules, the draft could be fixed editorially.
In theory, yes, but names are important and sticky, so I wouldn't
want to apply new names to the Working Draft without CWG and plenary
consent.
The scope here is a large-ish set of related names, likely needing
slightly involved fixes to the existing text. It would be good
if those changes could be presented in a coherent paper for
review.
Jens (co-editor)
_______________________________________________
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%7C6b0f9051c7614eda12e708da2deac86e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637872783663069438%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FqU29SAfH%2B8a2J199H1J%2BENhm1lJuZmeYVllbqQ%2Bfjs%3D&reserved=0
> In theory, yes, but names are important and sticky, so I wouldn't
> want to apply new names to the Working Draft without CWG and plenary
> consent.
Agreed.
While the current set of terms in the standards is not great, I would seriously caution against re-inventing the standards terminology from just tooling perspective.
First, we need to come up with the set of terminology for tooling; then see if those actually correspond to programmers practice of software construction; then see which subset of those term can be lifted into the C++ spec.
The upshot is that the needs for spec aren't exactly the same as those of tooling or the same as those of ordinary programmers.
-- Gaby
-----Original Message-----
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Jens Maurer via SG15
Sent: Wednesday, May 4, 2022 9:26 AM
To: sg15_at_[hidden]
Cc: Jens Maurer <Jens.Maurer_at_[hidden]>
Subject: Re: [SG15] P2581R0: Specifying the Interoperability of Binary Module Interface Files
On 04/05/2022 17.30, Steve Downey via SG15 wrote:
> If we can figure out a better set of names, or improve consistency, without changing the semantics of modules, the draft could be fixed editorially.
In theory, yes, but names are important and sticky, so I wouldn't
want to apply new names to the Working Draft without CWG and plenary
consent.
The scope here is a large-ish set of related names, likely needing
slightly involved fixes to the existing text. It would be good
if those changes could be presented in a coherent paper for
review.
Jens (co-editor)
_______________________________________________
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%7C6b0f9051c7614eda12e708da2deac86e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637872783663069438%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FqU29SAfH%2B8a2J199H1J%2BENhm1lJuZmeYVllbqQ%2Bfjs%3D&reserved=0
Received on 2022-05-04 17:27:06