[PATCH] D50119: P1144 "Trivially relocatable" (0/3): Compiler support for `__is_trivially_relocatable(T)`

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone added a comment.

In D50119#1808616 <https://reviews.llvm.org/D50119#1808616>, @rjmccall wrote:

> If the committee is actively looking into this problem and considering multiple alternatives, I don't see a particular need to accept your proposal into Clang in advance of the committee's decision.  Arguably that would even be somewhat inappropriate, since it might be seen as an endorsement of your proposal over the alternatives, which I don't believe anyone from Clang has looked into.  Letting the committee make a decision also addresses our disagreements about the language design and avoids introducing unnecessary divergence if the eventually-accepted design doesn't match your proposal.
>
> Having a workable patch that you've taken advantage of in various projects should count as implementation experience for the committee's purposes.
>
> If the committee *isn't* taking this up, they absolutely should, though.


I see the situation as exactly the opposite of what you just said. We cannot get implementation experience without an implementation. I would like Clang to be that implementation. But if Clang refuses to implement anything that is not Standard C++, then we have a chicken-and-egg problem: nobody can experiment with TR on real codebases until a compiler supports it. I would like Clang to be that compiler.

I don't plan to pursue P1144 <https://reviews.llvm.org/P1144> any more in the ISO C++ Committee until someone has succeeded in implementing it in a compiler and letting people like Mark Elendt <https://www.youtube.com/watch?v=2YXwg0n9e7E&t=41m57s> actually use it. You can say "ISO ought to take this up" all you want, but if no vendor is willing to implement the feature even with a pull request in hand, it's hardly fair to ask ISO to save you by standardizing it _before_ the implementation experience is in. They should be spending their time standardizing existing practice. That WG21 has been really really bad about standardizing vaporware lately is *not* a good trend, and I do not plan to encourage the trend.

Can you explain what is the distinction you draw between a new vendor-specific attribute like D70469 <https://reviews.llvm.org/D70469> `[[clang::acquire_handle]]` or D70520 <https://reviews.llvm.org/D70520> `[[clang::export_name]]` or D60455 <https://reviews.llvm.org/D60455> `[[clang::sycl_kernel]]`, and a new vendor-specific attribute like D50119 <https://reviews.llvm.org/D50119> `[[clang::trivially_relocatable]]`? What's the secret sauce that permitted those extensions even as this one has stalled for years?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D50119/new/

https://reviews.llvm.org/D50119