On Thu, Jun 9, 2022 at 10:31 AM Daniela Engert via Core <
core_at_[hidden]> wrote:

> Am 09.06.2022 um 09:55 schrieb Boris Kolpackov via SG15:
> > Gabriel Dos Reis via SG15 <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. 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 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]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core
> Link to this post: http://lists.isocpp.org/core/2022/06/12661.php
>