cor3ntin wrote: > 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 am not sure i understand, assignability is already a transitive property for defaults operators? so the scenario you are concerned about is triviality copyable types with a user defined assignment operators? This would for example not impact reference wrappers which are not assignable. The larger point is that there are 2 concerns here, one is whether it is safe to relocate a type at the language level, which this type trait is intended to provide, and one is how a library uses relocatability for optimization. A library may decide it doesn't want to relocate types that are not assignable for some operations (which btw doesn't need to apply recursively to subobjects) , and it can do so today. I would in fact imagine that the logic would be 1/checking for assignability in all cases 2/checking for relocatability for optimization. It would be useful to illustrate with code examples scenarios in which that wouldn't work. And again, https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2959r0.html goes into some of these questions and might be worth checking out. https://github.com/llvm/llvm-project/pull/84621 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
