Some of the expectations for the std and std.compat modules are implied in
https://eel.is/c++draft/library#std.modules-4 . This suggests that the ABI
is affected by which module you are attached to, but that there is a way to
get identical ABI to #includes through some approach or another (generally
`extern "C++"` blocks). It also implies that ABI compatibility with
modules doesn't "just happen".

On Thu, Jan 18, 2024 at 2:00 AM Chuanqi Xu via Ext <ext_at_[hidden]>
wrote:

>
> Yeah, I just made a simple draft:
> 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_[hidden]>; 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]>
> wrote:
> Hi Experts,
>
> There is a discussion about ABI in modules in
> 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) 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
>
>
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2024/01/22480.php
>