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.