On Mon, 2025-06-09 at 13:14 -0700, Oliver Hunt wrote:
>
>
> > 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]>
> > > > > 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.
>

Perhaps "ignore" is too harsh.

The Standard should be implementable without breaking the ABI.

However, the Standard should not refrain from adopting features on the
grounds that an ABI break is required to benefit from them. It should
be left up to the vendors to decide if they want to bump the ABI or
not.

> > > > >
> > > > > > 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,


If the Standard says "X is required" because previous platforms did X,
then it's annoying.

If the Standard relaxes X so that it's no longer required, then older
platforms can continue to do X, and the new platform does not.

To go back to std::optional, existing platforms must conditionally
destroy the carried value, but we don't have to mandate it for future
platforms.

>
> >
> > 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.


I agree we shouldn't force ABI problems. But neither should we reject
features because existing platforms can't benefit from them due to 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.

It's not free and yet people want it. One example is
[[clang::trivial_abi]]. Another is the fact that callers are
responsible for destruction of callee function parameters on some
platforms, which interferes with relocating objects into callees.


>
> > 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.
>

Not at all. I explained that the proposal is in two parts - one to
define a dummy value protocol, and the other to actually use it in
std::optional. The decision to use it is left to the vendor depending
on whether they want to implement it or not (it has no visible effects
apart from performance).



> 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,

I was being facetious, I guess that's risky and a bad idea on lists
such as this.


> 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.


I don't agree with the current stance that if something doesn't fit
with the current ABI, it is immediately rejected. I think it will
ossify the language, which is already facing significant competition.

As far as I can tell, Rust doesn't have any ABI stability. If they need
to make a change, they do it. I understand it's far more difficult for
a language with multi-decade baggage, but I don't think it has to be
addressed.