Date: Mon, 09 Jun 2025 13:14:57 -0700
> On Jun 9, 2025, at 12:11 PM, 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] <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
>
> 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] <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 20:15:13