Date: Mon, 9 Jun 2025 21:04:28 +0000
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_apple.com>; std-proposals_at_[hidden]
Subject: Re: [std-proposals] ABI breaks
On Jun 9, 2025, at 12:11 PM, Avi Kivity <avi_at_[hidden]<mailto: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]<mailto: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]<mailto: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
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_apple.com>; std-proposals_at_[hidden]
Subject: Re: [std-proposals] ABI breaks
On Jun 9, 2025, at 12:11 PM, Avi Kivity <avi_at_[hidden]<mailto: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]<mailto: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]<mailto: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
Received on 2025-06-09 21:04:33