[PATCH] D50119: Compiler support for P1144R0 "__is_trivially_relocatable(T)"

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In https://reviews.llvm.org/D50119#1303423, @Quuxplusone wrote:

> In the `unordered_set [[maybe_trivially_relocatable]]` patch, I must wrap the attribute in a macro `_LIBCPP_MAYBE_TRIVIALLY_RELOCATABLE_UNLESS_DEBUG`. Without this caveat, I would have ended up with //unsafe behavior// in debug mode. The `unordered_set [[trivially_relocatable]]` patch does not have this danger; the fact that we break the Rule of Zero in debug mode is sufficient to disable trivial relocatability.


Can you elaborate?  Providing a non-defaulted copy/move constructor or destructor should make an unannotated class non-trivially-relocatable under both rules.

> In the `unordered_set [[maybe_trivially_relocatable]]` patch, I must either pipe the attribute down through `unique_ptr`, or else give up using `unique_ptr` in `__hash_table`. I chose to modify `unique_ptr`; but note that many working programmers wouldn't have this luxury. In the `unordered_set [[trivially_relocatable]]` patch, I don't need to modify `unique_ptr`; I just use the "triviality-forcing wrapper" pattern.

Sure, this is an acknowledged downside of `[[maybe_trivially_relocatable]]` for third-party programmers.

> I still believe it is impossible to implement `std::optional` with only `[[maybe_trivially_relocatable]]`.

This might also need elaboration.


Repository:
  rC Clang

https://reviews.llvm.org/D50119