Those are about source-level compatibility. I'm not proposing any
change here.

To make it concrete, to provide source-level compatibility for
std::optional you'd #ifdef features introduced in newer C++ Standards
(or deprecated/removed features). To provide ABI level compatibility,
you'd #ifdef layout and behavioral changes.

On Mon, 2025-06-09 at 23:16 +0200, Sebastian Wittmeier via Std-
Proposals wrote:
>
> There are some projects, which mix C++ versions, e.g. by sub-
> project/component.
> There also are libraries, which are compatible with more than one C++
> version.
>
> > -----Ursprüngliche Nachricht-----
> > Von: Tiago Freire via Std-Proposals <std-
> > proposals_at_[hidden]>
> > Gesendet: Mo 09.06.2025 23:04
> > Betreff: Re: [std-proposals] ABI breaks
> > An: std-proposals_at_[hidden]; Avi Kivity <avi_at_[hidden]>;
> > CC: Tiago Freire <tmiguelf_at_[hidden]>;
> >
> > I think we are putting the cart in front of the horses here.
> >
> >
> >
> > ABI breaks are an important consideration but not the ultimate
> > consideration.
> >
> >
> >
> > If we can have a feature without breaking ABI, that is better, no
> > need to go trough all that effort if you can avoid it.
> >
> >
> >
> > And if the standard makes a change that breaks ABI, guess what?
> > Next day, absolutely nothing happens, code will not automatically
> > be broken. Things that used to build before will still build and
> > work in the same way the day after.
> >
> > It takes time and effort to move a code base to a new standard and
> > it is something that occurs intentionally.
> >
> > Your code that compiles on C++20 will still compile on C++20.
> >
> > The problem is going to be for projects that want to migrate to a
> > new standard because of feature X, but they have to deal with
> > unwanted feature Y.
> >
> > It’s not a “oh no, this is a deal breaker, we have no way to handle
> > this”… C++ is a language for practical applications, the problem is
> > practical, it costs money to upgrade.
> >
> > Is your feature worth the impact of possibly millions of dollars
> > that it will cost to upgrade an ABI? If not, probably its best not
> > to do it.
> >
> > If it’s really worth it, maybe we can package that work overtime
> > and do it anyway, but it must be really worth it (it costs a lot of
> > people a lot of money).
> >
> >
> >
> > Come up with the feature first, and then we will see if it’s worth
> > it.
> >
> >
> >
> >
> >
> > From: Std-Proposals <std-proposals-bounces_at_[hidden]> On
> > Behalf Of Oliver Hunt via Std-Proposals
> > Sent: Monday, June 9, 2025 10:15 PM
> > To: Avi Kivity <avi_at_[hidden]>
> > Cc: Oliver Hunt <oliver_at_[hidden]>; std-proposals_at_[hidden]
> > Subject: Re: [std-proposals] ABI breaks
> >
> >
> >
> >
> >
> >
> >
> >
> > >
> > > On Jun 9, 2025, at 12:11PM, Avi Kivity <avi_at_[hidden]> wrote:
> > >
> > >
> > >
> > > On Mon, 2025-06-09 at 04:39 -0700, Oliver Hunt wrote:
> > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > On Jun 9, 2025, at 4:17 AM, Avi Kivity via Std-Proposals
> > > > > <std-proposals_at_[hidden]> wrote:
> > > > >
> > > > >
> > > > >
> > > > > On Sun, 2025-06-08 at 23:40 +0300, Ville Voutilainen wrote:
> > > > >
> > > > > >
> > > > > > On Sun, 8 Jun 2025 at 11:45, Avi Kivity <avi_at_[hidden]>
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > Sure, but it was painful. Very painful. It's not quite
> > > > > > > that painful
> > > > > > >
> > > > > > > for std::optional, because it's not used elsewhere in the
> > > > > > > library
> > > > > > >
> > > > > > > internals.
> > > > > > >
> > > > > > > But still, it's painful.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > It wasn't painful for me - I barely noticed it. Of
> > > > > > > course, everyone's mileage varies.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > In my opinion, in these days of containers, it's much
> > > > > > > easier to support multiple ABIs.
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > I don't think everybody uses containers.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > I don't think the Standard should concern itself with
> > > > > > > ABIs. It should promote source compatibility. It should
> > > > > > > be up to the vendors to decide whether to race ahead or
> > > > > > > be conservative.
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > I think the standard should concern itself with how the
> > > > > > things
> > > > > >
> > > > > > specified in it can be deployed.
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > The Standard should not make decisions that cannot be
> > > > > implemented. But it also should not refrain from making
> > > > > decisions that cannot be implemented optimally on every
> > > > > platform, and instead leave it to the platform to make a
> > > > > choice.
> > > > >
> > > >
> > > >
> > > >
> > > > It does do exactly that. That’s why it limits the extent to
> > > > which it describes the core implementation details. The lack of
> > > > those explicit definitions are what allow - but do not require
> > > > - things like the small string optimizations that
> > > > implementations do. They allow the various security mitigations
> > > > present in many implementations of the standard library and the
> > > > underlying language implementation.
> > > >
> > > >
> > > >
> > > > That’s not what you’re asking for though, you’re asking to
> > > > permit design that means that people cannot rely on software
> > > > that works today working tomorrow, without recompilation. But
> > > > by definition that recompilation will not work on older
> > > > systems.
> > > >
> > >
> > >
> > >
> > >
> > >
> > > Not at all. A vendor can implement std::optional that ignores the
> > > dummy value protocol. That won't see any performance gains but
> > > will work exactly the same. Or they can implement std::optional
> > > with the dummy value protocol, and require everyone to recompile.
> > > Or they can add a #ifdef and push the decision to their
> > > downstream.
> > >
> >
> >
> >
> > I’m not talking about std::optional though - I’m addressing your
> > claims that the standard should ignore ABI impact of changes.
> >
> >
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Distribution vendors already rebuild all their packages
> > > > > > > for each major release, and third-party vendors already
> > > > > > > build for multiple architectures. Having them build for
> > > > > > > the most recent and next-recent ABI is annoying, but not
> > > > > > > more than that.
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > You're talking about doubling the amount of ABIs a vendor
> > > > > > needs to
> > > > > >
> > > > > > target. That's a non-trivial exercise.
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > It is not a trivial exercise. But are we not dooming the
> > > > > language if we freeze some features to a set of decisions
> > > > > made some time in the 90's?
> > > > >
> > > >
> > > >
> > > >
> > > > No.
> > > >
> > > >
> > > >
> > > > Every language is destined to eventually have some rules or abi
> > > > decisions from early in its life become subject to hyrum’s rule
> > > > and functionally unchangeable.
> > > >
> > > >
> > > >
> > > > Your options as a language developer are
> > > >
> > > >
> > > >
> > > > (a) Pretend that you will never need to worry about ABI
> > > >
> > > > (b) Acknowledge that eventually you will hit ABI stability
> > > > problems
> > > >
> > > >
> > > >
> > > > If you choose (a), you end up making poor design choices that
> > > > can then - by random happenstance - become functionally fixed
> > > > ABI as you hit stage two of a successful language where the
> > > > ABI becomes fixed.
> > > >
> > > >
> > > >
> > > > (b) means you acknowledge that your design work is subject to
> > > > constraints, and you need to spend time on the upfront design
> > > > to limit how much you get bound by ABI constraints in the
> > > > future.
> > > >
> > > >
> > > >
> > > > Things like the semantics of unordered_map that you’re clearly
> > > > unhappy about are the result of (a), which is what you are
> > > > pushing for. The result of that path is that design decisions
> > > > are made that expose suboptimal ABIs that you subsequently get
> > > > stuck with[1], despite your belief that ignoring ABI will
> > > > result in more freedom for implementations, the end result is
> > > > that there is not any real change in the ABI constraints that
> > > > implementations need to support, but that the library features
> > > > that are impacted are made worse as they’re designed with a
> > > > false assumption that their claim to not care about ABI will
> > > > permit them to change their abi in future.
> > > >
> > > >
> > > >
> > > > The fundamental issue here is that you believe that thinking
> > > > about ABI impact results in worse outcomes than ignoring it,
> > > > because you’re considering the here and now, and not the
> > > > consequences ten or twenty years from now. Failing to consider
> > > > the ABI impact results in design decisions that may turn out to
> > > > be wrong becoming a functionally stuck part of the ABI,
> > > > *precisely* because the ABI impact was not considered.
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > When some of those unfortunate [2] ABI decisions were made,
> > > people were using 32-bit systems. Now we're all on 64-bit
> > > systems, so clearly an ABI transition was made. In fact, your
> > > employer changed their ISA multiple times, a much larger change.
> > >
> >
> > >
> > >
> > >
> > > It's clearly possible to change ABIs, from i386 to x86_64, even
> > > though it wasn't planned when the 80386 chip .
> > >
> >
> >
> >
> > Yes, and when you bring up a new platform, you implement the
> > existing standard, and at that point that is the ABI you are stuck
> > with.
> >
> >
> >
> > If the standard says “X is required” the new platform has to do
> > that. Is it annoying: yes. It’s also reality,
> >
> >
> >
> >
> > >
> > >
> > >
> > > What makes it difficult is that across the multi-decade life of
> > > the ABI, everyone has some multi-year interval where they can't
> > > change some object file. Those intervals all overlap and
> > > generate an infinite span where at least someone can't change.
> > > But there's no single .o file that survived all those years.
> > >
> >
> >
> >
> > Right, because you’re not understanding how platforms change. A new
> > platform/isa/architecture is brought up, and provides the standard
> > libraries as those libraries are specified, not some imagined
> > alternative. At that point the ABI is fixed.
> >
> >
> >
> > Again, as I said previously, that is why the standard *should*
> > consider ABI, as it means ensuring specifications are designed in
> > ways that don’t force potentially unwanted long term ABI problems.
> >
> >
> >
> > >
> > > The solution is to batch multiple changes into infrequent but
> > > meaningful transitions and support two ABI generations in
> > > parallel. Just like the i386/x86_64 transition.
> > >
> >
> >
> >
> > Supporting multiple concurrent ABIs is not free, and you’re asking
> > for multiple ABIs on the same ISA.
> >
> >
> >
> >
> > >
> > > Yes, it's quite onerous for the vendors, but since I'm not one of
> > > them, I don't mind.
> > >
> >
> >
> >
> > Yes, you’ve made it quite clear that you do not want to work with
> > constraints involved in defining language standards. These exist
> > for all language standards, and what changes is just *what*
> > constraints are involved. For languages like C and C++, ABI is a
> > constraint.
> >
> >
> >
> > The problem is you’re trying to make changes to a standard without
> > acknowledging the constraints of the standard you’re trying to
> > change. Your response to people expressing concern over the ABI
> > impact has been to say that ABI constraints don’t matter to you,
> > and so you don’t want to deal with them, and to then argue that you
> > should not have to because you disagree with those constraints. Now
> > I don’t know what the ABI issues with your proposal are, but if
> > people have raised concerns that your proposal does impact the
> > ABI, you need to at least address their concerns *in your proposal*
> > and explain why it does not impact the ABI. If you don’t do that
> > your proposal is incomplete.
> >
> >
> >
> > You should also consider that standards bodies consist of people,
> > and getting a proposal from idea to presentable proposal document,
> > and finally into the standard will require working with others. So
> > starting off by being dismissive of the concerns people have
> > raised, and then saying you don’t care about the design constraints
> > of the standard is just telling others that you aren’t serious
> > about the proposal, and so it’s not worth them spending time on it.
> > That does not kill your proposal, it just means you’ll have to do
> > even more work, and you’ll be doing it without feedback,
> > information, or help from a range of experienced and knowledgeable
> > people.
> >
> >
> >
> > —Oliver
> >
> >
> >