On Mon, 2025-06-09 at 08:44 -0400, Arthur O'Dwyer wrote:

On Mon, Jun 9, 2025, 7:12 AM Avi Kivity via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

On Sun, 2025-06-08 at 21:33 +0100, Jonathan Wakely wrote:


On Sun, 8 Jun 2025, 09:46 Avi Kivity, <avi@scylladb.com> 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@lists.isocpp.org> 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

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?"

Acknowledged. But today, such users can be moved to containers, and I don't see that a 10-year-old program needs a 1-day-old compiler. I think a 10-year deprecation cycle for ABIs is reasonable - an ABI lives for 20 years, and 10 years into its life we launch the next generation with accumulated fixes.