On Mon, Jun 9, 2025, 7:12 AM Avi Kivity via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sun, 2025-06-08 at 21:33 +0100, Jonathan Wakely wrote:
>
>
>
> On Sun, 8 Jun 2025, 09:46 Avi Kivity, <avi_at_[hidden]> wrote:
>
> On Sat, 2025-06-07 at 22:25 +0100, Jonathan Wakely wrote:
>
>
>
> On Sat, 7 Jun 2025, 22:20 Avi Kivity via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
> On Sat, 2025-06-07 at 21:57 +0300, Ville Voutilainen via Std-Proposals
> wrote:
>
> On Sat, 7 Jun 2025 at 21:44, Robin Savonen Söderholm via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>
>
> You can easily implement your own version of optional that does exactly
> that (it would even be a simpler class to implement, although not to use).
> The question then is why? If you somehow think that you would gain
> performance out of it, then my suggestion is: implement this type of
> optional and show both a benchmark where it makes a significant difference
> and tell us the use case where this performance gain can be leveraged.
>
> My 2 c.
>
>
> That's easy. The hard part is figuring out how to deploy such a type
> with the same name as its previous version that didn't use
> the dummy value protocol. It's a behavioral ABI break without any
> layout ABI break.
>
>
>
> This was solved already when std::string changed its ABI. The compilers
> shipped the standard library compiled in both modes for a while, then
> dropped the old mode.
>
>
> We didn't drop it, both modes are still supported (by a single binary) and
> in use today, and it took a year of my life and I don't want to do it again
> :-)
>
> And it still has costs today for every change to std::string (as we have
> to decide whether to implement the new stuff for the old mode too).
>
>
>
> Do people use the old string ABI?
>
>
> Yes, even with the very latest GCC releases, and not just because they're
> stuck on an ancient Linux distro.
>
>
> Amazing. I guess they're stuck with third-party object files that cannot
> be updated.
>

Yep. For example, my employer's codebase incorporates a third-party static
library for talking to a Vertica database, which library is (or, from my
non-expert viewpoint, seems to be) available only for Linux, only for
libstdc++, and only for the old libstdc++ string ABI. This means that the
program we want to link against it (the program that needs to talk to
Vertica) must be compiled with a special set of flags and can't be compiled
except on Linux to begin with. That's obviously a terrible position to be
in, but empirically somebody decided it was better than the alternative of
just not being able to use this third-party Vertica library at all. (Or
possibly, just better than figuring out how to update that library!)

I won't defend the absolute rightness of our cost/benefit analysis there;
but I do offer it as a concrete example of someone in production still
relying on the old string ABI even in the year 2025 — an answer to "Do
people still use the old string ABI?"

Arthur