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.


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

Adding the dummy value protocol does not impact ABI. Implementing it in
std::optional does, but we don't have to require it.


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

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.

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. Yes, it's quite onerous for the
vendors, but since I'm not one of them, I don't mind.







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


[2] I agree, of course


>
>
> >
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>