AaronBallman wrote: > So, I was completely unaware that trivial relocatability had been picked up > at all by WG21. Since the beginning of `trivial_abi`, I we were solidly in > the vendor-extension space trying to build non-standard but practical > solutions to real world problems, like the fact that we couldn't pass > `unique_ptr` in registers. We (users & implementers) have all collectively > identified trivial relocatability as an important optimization for > vector-like containers, and we're all looking for a solution to that. It > feels like this attempt to standardize this type trait is getting in the way > of our collective ability to add vendor extensions that were not necessarily > intended to become standards-track proposals.
The primary purpose of our documented requirement to put extensions like this in front of a standards body is because we trust the standards organizations to be more thorough about the features they add than we as implementers typically achieve. So this isn't the standardization process getting in the way of us adding extensions, it's our process being followed correctly. Our type traits are intended as the underlying implementation to be used for the standard library, so changing `__is_trivially_relocatable` to not follow what WG21 is doing is not the approach we should take. I don't think anyone is arguing against solving problems the standards body isn't solving with their solution. It's more that we're saying to start from first principles with a new feature that's not the one being standardized by WG21 (pick a new name, address issues raised by WG21 discussions, post an RFC describing why this is beneficial/necessary, etc). However, because WG21 has not finalized the feature, we should be careful before adding a new type trait to the compiler because WG21 does change their opinion occasionally. @rnk, Google is still a member of WG21, so perhaps it would be worth attending the upcoming meeting in St Louis to advocate for the design approach you prefer (if successful, then we don't need to add a secondary trait at all). 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
