Hi Dani and Ben,
 I should have addressed all your opinions in https://isocpp.org/files/papers/D3092R0.html <https://isocpp.org/files/papers/D3092R0.html > except I commented additionally below. I tried to give a new number like `D3092R1` but it looks like the system doesn't allow us to update the revisions for `D` papers.

---
> A module TU compiles into a BMI, an object file, or both.
I didn't add this since I am confused. In my mind, all importable module unit should be compiled into a BMI and an object file. And the implementation module unit should be compiled into an object file. Then what is the case that a module unit should be compiled into a BMI? Also I feel my description is more clear so I didn't take this.
Thanks,
Chuanqi
------------------------------------------------------------------
From: SG15 <sg15_at_[hidden]>
Send Time:2024 Jan. 19 (Fri.) 00:12
To:SG15<sg15_at_[hidden]>
Cc:Daniela Engert<dani_at_[hidden]>; Evolution Working Group mailing list<ext_at_[hidden]>
Subject:Re: [SG15] [RFC] [Modules] [ABI] Modules ABI requirement
Am 18.01.2024 um 08:00 schrieb Chuanqi Xu via SG15:
 Yeah, I just made a simple draft: https://isocpp.org/files/papers/D3092R0.html <https://isocpp.org/files/papers/D3092R0.html > to include things related to ABI and modules in my mind immediately.
It may be easy to miss some important points. So I retitled this thread and mark it as RFC. Please chime in freely if you find there is imprecise description or anything missed.
A few clarifications from my side:
3) every module TU of a named module has *exactly one* module declaration (no plural). Those, and all following declarations until the end of the TU are *part* of the module purview. This means, a module TU contains (a part of) the named module, and optionally a part of the global module. A module TU compiles into a BMI, an object file, or both.
4.1) Translation units *explicitly or implicitly* importing modules *must* call the initializer functions of the imported modules *within the sequence* of the dynamic-initializers in the TU. Initializations of entities at namespace scope are *appearance-ordered*. This (recursively) *extends* into imported modules at the point of appearance of the import declaration.
4.2) module linkage applies to *all non-TU-local* entities in the purview which don't get external linkage by other means like export or language linkage specifications. 'Inline' doesn't change attachment and therefore doesn't affect linkage in this respect.
5.1) "that what if internal linkage entites get imported?". You can't import them because they can't be exported in the first place.
Thanks
 Dani
Thanks,
Chuanqi
------------------------------------------------------------------
From:Michael Spencer <bigcheesegs_at_[hidden]> <mailto:bigcheesegs_at_[hidden] >
Send Time:2024 Jan. 18 (Thu.) 07:48
To:SG15<sg15_at_[hidden]> <mailto:sg15_at_lists.isocpp.org >
Cc:Evolution Working Group mailing list<ext_at_[hidden]socpp.org> <mailto:ext_at_[hidden] >; Chuanqi<chuanqi.xcq_at_[hidden]> <mailto:chuanqi.xcq_at_[hidden] >
Subject:Re: [SG15] Could we summarize precise ABI expectation for modules?
On Wed, Jan 10, 2024 at 9:14 PM Chuanqi Xu via SG15 <sg15_at_[hidden] <mailto:sg15_at_[hidden] >> wrote:
Hi Experts,
 There is a discussion about ABI in modules in https://github.com/itanium-cxx-abi/cxx-abi/issues/170 <https://github.com/itanium-cxx-abi/cxx-abi/issues/170 >. 
 John Said:
> Okay. The committee needs to understand that that's not how this works, alright? Whenever the language adds new constructs, compilers have to figure out how to compile them, and that needs to go into this specification. Modules add quite a few new constructs, and they have non-trivial implications for compilers because they create new kinds of information flow between translation units. The traditional understanding of ABI boundaries in C++ has always been that any information in the translation unit is fair game for the compiler to use. A perhaps-naive understanding of how importing a module interface unit works is that the exported declarations from that module are now available in the importing translation unit essentially as if they were declared there (just preserving the knowledge that they in fact came from a different module). So if the idea is now that some of the information in a module interface unit is not supposed to be used by its importers, that's an important shift. That's true even if you've identified a reasonable formalism that seems to unify previous behavior with the new intended interpretation, because compilers need to make sure they're implementing the intent of that formalism.
 Then I feel it is worth to bring the topic here. Should we try to summarize a precise ABI expectation for modules? And if yes, how should we get involved in? And although it is not required to be formal, I feel a paper might be a good outcome.
 BTW, previously I sent a discussion about ABI in modules to SG15 (https://lists.isocpp.org/sg15/2023/11/2064.php <https://lists.isocpp.org/sg15/2023/11/2064.php >) as I think it is implementation details. But given what John said, I feel it may be worthy to bring this to EWG too.
Thanks,
Chuanqi
I think it would be good to cover what expectations people actually have. Most of the committee's discussion has been around what implementation strategies are allowed, not really any guarantees the language is trying to make (as the language standard can't actually do that).
I think it would be best to phrase this as what source changes potentially impact ABI, and thus require recompiling all dependencies.
- Michael Spencer
_______________________________________________ SG15 mailing list SG15_at_[hidden] <mailto:SG15_at_[hidden] >https://lists.isocpp.org/mailman/listinfo.cgi/sg15 <https://lists.isocpp.org/mailman/listinfo.cgi/sg15 > 
-- 
PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5