C++ Logo

sg15

Advanced search

Re: P2581R0: Specifying the Interoperability of Binary Module Interface Files

From: Michael Spencer <bigcheesegs_at_[hidden]>
Date: Thu, 5 May 2022 11:08:38 -0600
On Wed, May 4, 2022 at 11:27 AM Gabriel Dos Reis via SG15 <
sg15_at_[hidden]> wrote:

> [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
>

I actually think we can come up with terminology that makes sense for both.
I think that the name "implementation partition" is particularly confusing
to people. When Daniel and I were discussing this at C++Now we found
meeting notes from 2018 where people were confused about them, and even
today I keep seeing confusion around what they actually are.

Now, "implementation partition" doesn't actually occur in the standard, but
an alternative name doesn't. People call them that because of the
combination of 10.1/2 (A module interface unit is a module unit whose
module-declaration starts with export-keyword; any other module unit is a
module implementation unit.) and 10.1/3 (A module partition is a module
unit whose module-declaration contains a module-partition). This wording
makes sense when reading all of chapter 10, but is quite confusing when
read alone.

A common misconception is that an implementation partition implements an
interface partition like a .h/.cpp pair. Another misconception is that
implementation partitions are just a way to split up an implementation, and
don't need BMIs.

The truth is that module implementation units that are also module
partitions are private interfaces. They define an interface that all
translation units of the same module can use. You would never use an
implementation partition if you did not want multiple other TUs to use it
as an interface to some common types or functionality.

I'm not completely sure yet how I would want to rename things in the
standard, but I do not believe we can continue to use and spread the
current name of "implementation partition" without continuing the mass
confusion.

- Michael Spencer


>
> -----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&amp;data=05%7C01%7Cgdr%40microsoft.com%7C6b0f9051c7614eda12e708da2deac86e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637872783663069438%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=FqU29SAfH%2B8a2J199H1J%2BENhm1lJuZmeYVllbqQ%2Bfjs%3D&amp;reserved=0
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>

Received on 2022-05-05 17:08:50