in that case, they will just be like any other TU of the program. No?

-- Gaby

________________________________
From: SG15 <sg15-bounces_at_[hidden]> on behalf of Richard Smith via SG15 <sg15_at_[hidden]>
Sent: Thursday, June 9, 2022 11:55:16 AM
To: sg15_at_[hidden] <sg15_at_[hidden]>
Cc: Richard Smith <richardsmith_at_[hidden]>; C++ Core Language Working Group <core_at_[hidden]>; Nathan Sidwell <nathan_at_[hidden]>
Subject: Re: [SG15] unimported implementation partitions

On Thu, 9 Jun 2022 at 08:06, Boris Kolpackov via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
Nathan Sidwell <nathan_at_[hidden]<mailto:nathan_at_[hidden]>> writes:

> Do not take GCC's behaviour here as evidence that it is the minimum of what
> should be happening.

Currently, listing an object file when linking an executable will
result in its static initializers being called. I think we need
a really good reason to now say that for some object files this
may or may not happen. Modules will be confusing enough as it is.

It's already the case that object files in archives generally only get linked, and their initializers only get run, if some symbol from the object file is used. Implementations can hand-wave this away as being conforming by saying the TUs corresponding to the other object files in the archive aren't part of the program. I don't think we can hand-wave in quite the same way for implementation partitions, though, because symbols defined in an implementation partition that's never imported might still be used. (Eg, if they're redeclared and used in another unit of the same module.)