[libc++] Make expected trivially assignable whenever possible

[Quuxplusone]

Since @huixie90 asked for a proof of concept — here it is!

Note that =deleted functions don't need to be hidden from ABI, nor do they need to be constexpr or noexcept or have any particular return type. Note that =defaulted functions shouldn't be explicitly marked constexpr or noexcept.

[frederick-vs-ja]

Is it intended not to consider is_trivially_destructible_v? (See also LWG4026 and P0602R4 which considered trivial destructibility.)

[Quuxplusone]

Today, is_trivially_copy_constructible_v<T> logically implies is_trivially_destructible_v<T>. (Godbolt.) There is some controversy about the desirability of this fact, but it's still a fact. So my personal view is that we shouldn't add redundant conditions that won't ever affect the conjunction's result. But I know that "reasonable people disagree," and I certainly wouldn't object if this were upstreamed with the redundant condition added.

---

Actually, in Hagenberg this very question came up during discussion of P2786's is_nothrow_relocatable, where the version approved in plenary has ([meta.unary.prop]):

is_trivially_relocatable_v<T> || (is_nothrow_move_constructible_v<remove_all_extents_t<T>> &&
                                  is_nothrow_destructible_v<remove_all_extents_t<T>>)

Today, is_nothrow_move_constructible_v<remove_all_extents_t<T>> logically implies is_nothrow_destructible_v<remove_all_extents_t<T>>, so personally I wouldn't have written it this way. But a vocal contingent on LWG did want the redundant condition, and since it has no effect there's no physical reason to oppose adding it, so, it got added.

[frederick-vs-ja]

Today, is_trivially_copy_constructible_v<T> logically implies is_trivially_destructible_v<T>.

Oh, I think this is arguable, as LWG2116 and LWG2827 aren't resolved yet.

I guess it's worthwhile to explicitly specify that multiple is_trivially_* imply is_trivially_destructible_v (or at least having a trivial non-deleted destructor), as we can hardly do anything special for a trivially-meowable but not trivially destructible class.

[Quuxplusone]

Today, is_trivially_copy_constructible_v<T> logically implies is_trivially_destructible_v<T>.

Oh, I think this is arguable, as LWG2116 and LWG2827 aren't resolved yet.

Sure, but LWG did vote in 2022 to close them as NAD/evolutionary (as shown in the minutes for LWG2116); I'm not sure why they haven't been actually closed in the issue system yet.

The evolutionary question is indeed argued. But I don't think such a change stands much chance precisely because there's already code just like the code I wrote, out there in the wild, which would quietly change semantics if we changed the meaning of these traits. In fact, notice that there exists a paper discussing why we might want to change the semantics of these traits (P2842R0, cplusplus/papers#1547 ), and its proposed resolution (§7 and §9) is literally to ratify LWG's position and close the issues as NAD — after all that it's still not proposing that we should change the traits!