[clang] [clang][Sema] Track trivial-relocatability as a type trait (PR #84621)

[Giuseppe D'Angelo via cfe-commits]

dangelog wrote:

I perfectly understand that Clang wants to implement the semantics that are being adopted by standard C++, so it wants to reserve `__is_trivially_relocatable` to match those semantics.

The amount of comments in this PR is however a strong signal that standard C++ is going directly against widely established practices. Qt won't need P2786 but P1144, because it uses trivial relocation not only ① for vector reallocation (that is: move *construction* + destruction via trivial relocation) but also ② for vector erase/insert (that is: move *assignment* (+destruction) via trivial relocation). It would not make sense for a type with a user-declared assignment operator to be considered TR for Qt.

Upstream C++ seems to be fine with just providing ① (via P2786), but that leaves a huge number of optimizations on the plate: vector insert, erase, swaps and swap-based algorithms, etc.; which is a total shame.

I perfectly understand that some types (like the aforementioned "reference wrappers", pmr::string, etc.) only allow ① semantics. If upstream cares about them so much and doesn't want to lose the opportunity of optimizing vector reallocation for them, why haven't they landed _two_ type traits? A generic "is trivial relocatable" (that captures construction and assignment) and a more specific one (that only captures construction; a subset of the first). It would make perfect sense to me to capture different semantics via different traits. Not only that, but P2786 has squatted the "trivial relocatable" name for the trait, which really belongs to the _more general_ trait.

Oh well, sorry for the rant :-)

> I don't think this accurate, If a library requires additional constraint, they can add them (in addition to checking the type trait), 

But this isn't useful at all; every library has already invented its own constraints and type traits. The point of having a language-based solution is that the "is TR" property gets automatically propagated when you compose types. No library solution can achieve that, especially lacking reflection.

> I don't think we should put efforts into supporting a P1144-based approach.

Do you mean that you would reject a proposal that adds Clang-specific trait (with another name) that implements P1144's semantics?

https://github.com/llvm/llvm-project/pull/84621