On 6/8/22 14:41, Gabriel Dos Reis wrote:
> Nathan -
>
> I am not sure I understand the issue. How would a program observe that an implementation partition isn't imported but is relevant to the behavior of the entire program?

Yes, it'd be a strange use, but it could be observed by the action of
its initializers:

module;
#include <stdio>
module my:secret;
int var = [](){return printf ("look at me!\n");}();

Do we make guarantees about the execution of that initializer?

>
> -- Gaby
>
> -----Original Message-----
> From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Nathan Sidwell via SG15
> Sent: Wednesday, June 8, 2022 10:23 AM
> To: C++ Core Language Working Group <core_at_[hidden]>; sg15_at_[hidden]
> Cc: Nathan Sidwell <nathan_at_[hidden]>
> Subject: [SG15] unimported implementation partitions
>
> Q1) Is there a use case for implementation partitions (a non-interface
> partition) that are not imported in any module unit? How would that
> differ from a regular implementation partition?
>
> We require all interface partitions be [transitively] imported in the
> primary interface. I don't think we require implementation partitions
> be imported at least once in a program.
>
> Q2) Is there a use case for a program to include a module interface that
> is not imported in any other TU (and has no implementation units)?
>
> The reason I ask is there an ABI issue with the global initializer
> function needed for p1874. I'm going to describe it in ELF terms, but I
> imagine the same choices appear in other ABIs.
>
> 1874 is solved by having each module primary interface, and all
> partitions, emit an idempotent initialization function that (a) calls
> the init fn of all imports and then (b) performs all dynamic inits of
> namespace scope.
>
> In a non-module world a function that performs #b would then arrange to
> be called at startup via .init or similar. In a module-world, we do not
> (need to) do this, as we know it'll be called somewhere by an import.
>
> However, Q1 raises the possibility that an implementation partition may
> not be imported anywhere, so its global initializer fn is never called
> from another global init. We therefore have to arrange for it to be
> called from .init as a regular initializer function. A small pessimization.
>
> Q2 raises the same question wrt primary interfaces. If they might never
> be imported, again, their initializer fn would never be called by that
> mechanism. We have to emit it via .init.
>
> nathan
>

-- 
Nathan Sidwell