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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
