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