On Mon, Jun 9, 2025 at 3:21 PM Avi Kivity via Std-Proposals <
std-proposals_at_[hidden]> wrote:

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

That's P2782 "is_trivially_value_initializable"
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2782r0.html>.
You can't use that trait in isolation, though; your `optional` would have
to check that destroying, copying, moving, assigning... the
value-initialized object doesn't have any side-effects *either*.
I can't immediately think of a type where
- `optional` could save a branch in, say, the assignment operator, in the
way you propose; and yet
- is_trivially_copyable<T> is false
When is_trivially_copyable<T> is true, `optional` itself can be trivially
copyable, so there's no branches to eliminate in that case anyway.

Since you've mentioned [[trivially_relocatable]] twice now:
(1) No, WG21 refuses to discuss P1144 [[trivially_relocatable]]. They've
shipped P2786 instead, which does not feature that attribute.
(2) Your earlier sketch of how `optional` could use trivial relocation
seemed incomplete to me. It's true that if T is trivially relocatable [in
the P1144 sense], then optional<T> can be trivially *relocatable* [in the
P1144 sense]. It is also true that if T is trivially relocatable then
optional<T> can be *branchlessly* move-assignable if you're willing to take
an ABI break. But it is definitely *not* true that if T is trivially
relocatable then optional<T> can be *trivially* move-assignable.
For more on both these points, see my recent blog posts
https://quuxplusone.github.io/blog/2025/05/08/siren-song-2-optional/
https://quuxplusone.github.io/blog/2025/05/09/siren-song-3-optional/

–Arthur