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.
Thanks,
Chuanqi
------------------------------------------------------------------
From:Michael Spencer <bigcheesegs_at_[hidden]>
Send Time:2024 Jan. 18 (Thu.) 07:48
To:SG15<sg15_at_[hidden]>
Cc:Evolution Working Group mailing list<ext_at_lists.isocpp.org>; Chuanqi<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