https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #17 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> --- (In reply to Marc Glisse from comment #16) > (In reply to Arthur O'Dwyer from comment #15) > > @Marc, it only now occurs to me that if libstdc++ uses > > `__is_trivially_relocatable` as its userspace type-trait name, then GCC > > won't be able to use `__is_trivially_relocatable(T)` as the name of its > > compiler builtin. (It would be analogous to if libstdc++ had used > > `__is_trivially_copyable` as the name of a type-trait.) > > Is there any chance that you could rename `__is_trivially_relocatable` to > > `__is_trivially_relocatablex` or `__has_trivial_relocatability` or something > > like that? Is it too late? I hope not. > > The name __is_trivially_relocatable is currently undocumented, it is an > implementation detail and users should not specialize it (or at least they > should be ready for it to break very easily). It can be renamed at any point > if convenient, say if/when gcc implements a builtin with the same name. Or > is the issue that clang already has such a builtin, and it now conflicts > with libstdc++? In that case I agree we should rename it. I don't care much > about the name, see what the maintainers are happy with... Agreed users should be ready for the library trait to break. Clang doesn't currently have such a builtin, but I am proposing it in https://reviews.llvm.org/D50119 (and I would rather rename the libstdc++ detail than the proposed Clang builtin). My concern is that if GCC/Clang EVER implement such a builtin, then that (newer) version of GCC/Clang would forever be unable to build this (older) version of libstdc++. I think that's not the end of the world, but I think we ought to preemptively avoid the situation if it's cheap to do so. I should have brought this up earlier, but as I said, it just dawned on me today.
