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.

Of course this little thing isn't worth the trouble, but libraries
could use a spring cleaning anyway (like make std::deque's default
constructor not allocate) and this could be added on top. Library
vendors that choose not to improve, would simply not implement the
feature.


> > P.S. you may already "pay" for a branch in the case of std::string
> > and the like due to SSO, I'm sure the compiler can do something
> > smart with the extra branch in optional for both move and
> > destruction.
>
> Those branches are completely unrelated, so the compiler can't do
> anything there.

Right.