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.
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.