We spent a lot of time litigating this in the C++20 time frame,
particularly the impact of function definitions being visible or not.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1498r1.html and
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1779r3.html are
relevant.
Non-inline function definitions are not to be exported as part of the
module interface. Module implementers control the ABI of the module, even
without module implementation partitions. The presence of the `inline`
keyword has extra meaning in a module interface, and signals that the body
is available.

This has the tradeoff that the translated interface is not sufficient alone
to compile the module TU because it is incomplete.

On Wed, Nov 1, 2023 at 10:18 AM Daniel Ruoso via SG15 <sg15_at_[hidden]>
wrote:

> On Wed, Nov 1, 2023, 03:10 Mathias Stearn via SG15 <sg15_at_[hidden]>
> wrote:
>
>> I'd rather we leave the option of whether I care more about rebuilds and
>> ABI stability vs optimization to then end project doing the compilation
>> rather than mandating a specific set of tradeoffs
>>
>
> The underlying problem is deeper than that.
>
> We have a multi-vendor ecosystem. A library author releasing a pre-built
> library needs to manage the ABI compatibility when making changes to that
> library.
>
> That means it is imperative to have a definitive consistent answer to the
> question of "does this change require me to make a new SONAME for my
> library?".
>
> Library authors that want to preserve ABI compatibility across releases
> need to use various techniques in order to allow changes without breaking
> compatibility (see also "How to write shared libraries", by Ulrich Drepper).
>
> Module interface units introduce a new category for C++ code, as now we
> have non-inline functions that are technically available to the caller.
> Before modules, only inline functions could be visible to the call site.
>
> There are two options:
>
> 1) non inline functions are visible to callers, which means they need to
> be treated as if they were inline for the purpose of managing compatibility.
>
> 2) non inline functions are not visible to callers, which means changes to
> their bodies have no impact on backwards compatibility.
>
> I have no strong opinion one way or another. My only strong opinion is
> that this has to be a consensus in the entire ecosystem, and properly
> documented and communicated, so library authors can decide if they should
> put a non-inline function in the interface unit or move it to an
> implementation unit.
>
> Daniel
>
>> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>