[Mathias]

  * So the most logical conclusion is that implementation partitions are made part of the program image in the same way as every other TU in the program (outside the purview of the ISO C++ standard, ie in the build system).

By the same token, they would be subject to the same lack of guarantees that other Tus enjoy. No?


  * I'm guessing it is too late to DR implementation partitions out of existence as more trouble than they are worth? ;)

I would prefer a fix that makes the interface vs. implementation correspondence more useful, e.g. make them implementation partitions of interface partition, and maybe provide a special syntax for what is specified in C++20 to avoid confusion.

-- Gaby


From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Mathias Stearn via SG15
Sent: Thursday, June 9, 2022 1:56 AM
To: C++ Core Language Working Group <core_at_[hidden]>
Cc: Mathias Stearn <redbeard0531+isocpp_at_[hidden]>; sg15_at_[hidden]; Nathan Sidwell <nathan_at_[hidden]>
Subject: Re: [SG15] [isocpp-core] unimported implementation partitions



On Thu, Jun 9, 2022 at 10:31 AM Daniela Engert via Core <core_at_[hidden]<mailto:core_at_[hidden]>> wrote:
Am 09.06.2022 um 09:55 schrieb Boris Kolpackov via SG15:
> Gabriel Dos Reis via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> writes:
>
>> How would a program observe that an implementation partition isn't
>> imported but is relevant to the behavior of the entire program?
> The implementation partition can register itself (as part of the
> static initialization) in some registry.
>
> For example, the implementation partition may include a unit test
> (because that's the only way to access the private parts) which
> is registered with the test harness.

The standard is totally silent about module partitions [module.unit]/3
that are also module implementation units [module.unit]/2, and which are
not required to be reachable [module.reach]/2 because they are not part
of the interface dependency [module.import]/10 graph of a module. They
may or may not have semantic effects.

If you want the behaviour from your example be portable you need to form
an interface dependency to that partition.

The standard _isn't_ really silent on that. Or at least any more than it is silent on how only other TU is made part of the "program image" in http://eel.is/c++draft/lex.phases#1.9<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Flex.phases%231.9&data=05%7C01%7Cgdr%40microsoft.com%7C01f5c556f32c436d948e08da49f5e3aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637903617700566954%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mZ1iglTyEQcIwjphm9w%2FUVECRCLaF9QwZzO0yZjpkxU%3D&reserved=0>. So the most logical conclusion is that implementation partitions are made part of the program image in the same way as every other TU in the program (outside the purview of the ISO C++ standard, ie in the build system). Consider the following program:

module m:part;
import m;
static auto _ = puts("init");
void foo() { puts("foo"); }

export module m;
export void foo();

import m;
int main() { foo(); }


Either the m:part TU is part of the program, and it is well defined that "init" and "foo" will be printed (the http://eel.is/c++draft/basic.start.dynamic#5<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fbasic.start.dynamic%235&data=05%7C01%7Cgdr%40microsoft.com%7C01f5c556f32c436d948e08da49f5e3aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637903617700566954%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XECEC4u06hAWvd%2FgPpfTwkYaL7GM%2BZ7e3B3iQFc%2BU%2Fg%3D&reserved=0> loophole doesn't apply here), or that TU isn't part of the program and you have an ODR violation because there was no definition of foo (and in practice, you would expect a linker error rather than successful compilation). I don't think there is any way to read the standard such that it allows "foo" to be printed but not "init". I'm intentionally ignoring the trivial sense that you could declare this an ODR violation and under IFNDR anything can happen.

To be clear, I'm not saying that that TU _should_ say m:part rather than just m, just that it shouldn't change the behavior if it does.

I'm guessing it is too late to DR implementation partitions out of existence as more trouble than they are worth? ;)


_______________________________________________
Core mailing list
Core_at_[hidden]<mailto:Core_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fcore&data=05%7C01%7Cgdr%40microsoft.com%7C01f5c556f32c436d948e08da49f5e3aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637903617700566954%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fZwg%2BgUCXusMXmEGTA3CHDMzmR40%2BdJKpz6GDphmsjA%3D&reserved=0>
Link to this post: http://lists.isocpp.org/core/2022/06/12661.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fcore%2F2022%2F06%2F12661.php&data=05%7C01%7Cgdr%40microsoft.com%7C01f5c556f32c436d948e08da49f5e3aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637903617700566954%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Z1%2FwBbEjwFvrApH42Ub27vh6tyQthU%2FQM106F8PuNkE%3D&reserved=0>