There is no guarantee that nullptr is represented as 0x0.   -----Ursprüngliche Nachricht----- Von:Avi Kivity via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 09.06.2025 21:22 Betreff:Re: [std-proposals] ABI breaks An:Ville Voutilainen <ville.voutilainen_at_[hidden]>; CC:Avi Kivity <avi_at_[hidden]>; std-proposals_at_[hidden]; On Mon, 2025-06-09 at 16:04 +0300, Ville Voutilainen wrote: On Mon, 9 Jun 2025 at 14:17, Avi Kivity <avi_at_[hidden] <mailto:avi_at_[hidden]> > wrote: The Standard should not make decisions that cannot be implemented. But it also should not refrain from making decisions that cannot be implemented optimally on every platform, and instead leave it to the platform to make a choice.  Well, that leads to this question: would you like it to be portably reliable that destroying a vector<optional<vector<optional<string>>>> is fast, or would you like it to be theoretically but not practically fast?    That's a good question.   You can get the first part without such problems if you bite the bullet and make it a separate type.  But that might not work, of course, because the committee might not want it.    Well, I don't want it either. There's a lot of value in having vocabulary types one uses everywhere.  I'm not above reimplementing those vocabulary types (in fact, I have my own string, born when libstdc++ std::string was still copy-on-write) but it's not worthwhile to avoid a branch.   You could try the second part, but that's then not portable because some vendors might not want it, and chances are that none of them want it, so it's portable in the sense that no practical implementation provides it.  I'm not dismissing the idea, I love it; if I had a time machine, I'd travel back in time and incorporate such a "cheap to default-construct, so do that instead of constructing nothing" into optional's design. But it's quite a different exercise to try to adapt it in afterwards.  I'm rather asking for a dummy value protocol, and leave it to implementations and user types to choose whether to incorporate it into std::optional or their own type.  Perhaps a different angle: just as we have [[trivially_relocatable]] (move+destroy == memcpy), add [[trivially_constructible]] and define it to memset(p, 0, sizeof). This works for unique_ptr, the trivial types, std::string, many others. User classes can use it to optimize unions and implementations can choose whether to use it in std::optional or not.   -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals