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

>