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

<std-proposals@lists.isocpp.org> 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.