Date: Sat, 7 Jun 2025 22:25:13 +0100
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).
> 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.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/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).
> 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.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2025-06-07 21:25:31