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