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?