Date: Mon, 09 Jun 2025 04:39:52 -0700
> 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.
Everyone understands that there were errors made in the past (std::unordered_map’s semantics are just one case), and those problems are unfortunate. The problem there is not that the standard did not consider abi impact, but that it overspecified the implementation and in doing so forced what turned out to be a suboptimal implementation for many use cases.
The solution to problems like that is not to ignore abi impact, but rather to recognize how choices will impact abi, and only specify what is actually required. Vendors are then able to provide implementations of the standard library that meet specified requirements, and developers can rely on not needing to recompile their software for every OS or platform update.
>
>
>>
>>> 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.
—Oliver
[1] To be clear I am not saying that people were dumb, or made bad choices. At the time those choices were presumably quite reasonable, but predicting the future is hard (otherwise I’d buy some lottery tickets and retire).
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> 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.
Everyone understands that there were errors made in the past (std::unordered_map’s semantics are just one case), and those problems are unfortunate. The problem there is not that the standard did not consider abi impact, but that it overspecified the implementation and in doing so forced what turned out to be a suboptimal implementation for many use cases.
The solution to problems like that is not to ignore abi impact, but rather to recognize how choices will impact abi, and only specify what is actually required. Vendors are then able to provide implementations of the standard library that meet specified requirements, and developers can rely on not needing to recompile their software for every OS or platform update.
>
>
>>
>>> 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.
—Oliver
[1] To be clear I am not saying that people were dumb, or made bad choices. At the time those choices were presumably quite reasonable, but predicting the future is hard (otherwise I’d buy some lottery tickets and retire).
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-06-09 11:40:09