Date: Wed, 8 Jun 2022 22:31:48 +0200
On Wed, 8 Jun 2022 at 22.11 Daniel Ruoso via SG15 <sg15_at_[hidden]>
wrote:
> Em qua., 8 de jun. de 2022 às 15:51, Herring, Davis <herring_at_[hidden]>
> escreveu:
> > The converse does not hold, so I would not expect the behavior of
> > a well-formed program that includes an implementation partition T
> > by virtue of explicit nomination to the linker to change if an import
> > of T is introduced in an otherwise empty translation unit. If the
> importer
> > is non-empty, of course, [basic.start.dynamic]/2.2 may cause the
> > import to change the order of non-local initialization, as well as
> > suppressing the freedom otherwise afforded by /5 to ignore entirely
> > a translation unit that contains just an unused variable with side
> effects in its initializer.
>
> I would actually go further and say that for a module internal
> partition to be a part of the program, it needs to be imported by a
> translation unit that is itself part of the program. So recursively,
> if the only thing importing a module is something that is ignored by
> the linker, it's the same thing as it not being imported anywhere.
Are you saying that changing
module m;
to
module m:part;
can break a working program? That seems like an unfortunate interpretation
to me.
>
> daniel
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
wrote:
> Em qua., 8 de jun. de 2022 às 15:51, Herring, Davis <herring_at_[hidden]>
> escreveu:
> > The converse does not hold, so I would not expect the behavior of
> > a well-formed program that includes an implementation partition T
> > by virtue of explicit nomination to the linker to change if an import
> > of T is introduced in an otherwise empty translation unit. If the
> importer
> > is non-empty, of course, [basic.start.dynamic]/2.2 may cause the
> > import to change the order of non-local initialization, as well as
> > suppressing the freedom otherwise afforded by /5 to ignore entirely
> > a translation unit that contains just an unused variable with side
> effects in its initializer.
>
> I would actually go further and say that for a module internal
> partition to be a part of the program, it needs to be imported by a
> translation unit that is itself part of the program. So recursively,
> if the only thing importing a module is something that is ignored by
> the linker, it's the same thing as it not being imported anywhere.
Are you saying that changing
module m;
to
module m:part;
can break a working program? That seems like an unfortunate interpretation
to me.
>
> daniel
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
Received on 2022-06-08 20:32:00