rjmccall added a comment. In D50119#1808727 <https://reviews.llvm.org/D50119#1808727>, @Quuxplusone wrote:
> 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. We have implementation experience: it's been implemented, and you have some experience using it. And LLVM/clang is a github project now, so you can easily make a fork somewhere with your patch applied, and people can build and use that compiler to get additional user experience. What you're asking now is for us to officially declare this to be a supported feature by putting it in our upcoming releases. I personally am not very fond of the proposed language design, so I'm not inclined to make that declaration. However, I don't speak for the entire clang project, and if consensus among other contributors is to take it, I won't block that. And of course we'll take it if the committee standardizes it. > 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? We are generally more conservative about taking features that are squarely about core language semantics and thus of direct interest to the language committee. The acquire/release attributes enable an interesting static analysis that it's hard to imagine would ever be standardized. `export_name` is a target-specific attribute. `sycl_kernel` is a standard part of the independently-standardized SYCL language extension. In contrast, this proposal describes a new core property of types, with complex interactions with the core language rules for implicit special members, and which clearly ought to be adopted throughout the standard library. And, as mentioned, you haven't sold us on the design. 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
