aaron.ballman added a comment. In https://reviews.llvm.org/D37436#868295, @hfinkel wrote:
> In https://reviews.llvm.org/D37436#867965, @aaron.ballman wrote: > > > In https://reviews.llvm.org/D37436#867287, @rsmith wrote: > > > > > If this is just supposed to be an experiment to get feedback on the > > > feature, then I don't think we should be treating it as a different > > > attribute syntax at all. Rather, I think we > > > just want to permit C++11 attributes to be parsed in other language > > > modes. If/when this becomes part of some future C working draft, I think > > > that's the time to have a > > > separate attribute syntax with a distinct set of valid unqualified > > > attribute names. > > > > > > I do not think that's the correct approach. These are not C++ attributes > > (for instance, no `using` insanity is allowed, `::` is a new lexing token > > in C, etc). Also, I don't think it's a good idea to enable all C++11-style > > attributes in C mode without giving each attribute some appropriate thought > > (what does `abi_tag` *do* in C mode? What happens with _Noreturn vs > > [[noreturn]] etc). Also, I'm not comfortable adding a bunch of > > vendor-specific `gnu::` attributes that GCC does not implement in C yet. > > > On this last point, I disagree. Implementation experience is about all of the > messy things that occur in production. In production, if we have this syntax, > then we'll end up enabling it for a bunch of vendor-specific attributes. Do > you think that we wouldn't? I'm sure we would. Also, FWIW, I was planning to traverse the attributes we implement to find which clang-specific C++ attributes would make sense to also enable as a follow-up patch once the syntax is in. > N2137 specifically talks about this as a use case. If so, this will include > `gnu::` attributes that we have in Clang (even if GCC does not implement > them). Eventually, yes, but it seems like a problem to implement something under that vendor namespace when the vendor themselves do not. I think it would be really unfortunate were GCC to add a C++ attribute named [[clang::frobble]] that Clang does not implement, and I don't see this case as being all that different. My belief is that GCC will eventually elect to make most of these attributes available in C mode and that's an appropriate time for us to do the same for their vendor namespace. > From my perspective, lack of consistency here between Clang's C and C++ modes > is much more problematic than a lack of consistency between what Clang and > GCC implement. From my perspective, they're both problems in their own right. To me (and maybe I'm weird with this line of reasoning), the only reasonable time to implement an attribute under another vendor's attribute namespace is when you are promising your users that you will attempt to match the owning vendor's semantics for that attribute. A case could be made here that the owning vendor *has* implemented that attribute (since they have in C++), but I'm not too comfortable *assuming* that the GCC folks are okay with this since they don't implement the feature syntax in C yet. That said, I'm happy to ask Jason at the meetings in Albuquerque to explore the idea -- but I don't think it should hold up this patch, especially since we have our own vendor attributes we can use for gaining experience. https://reviews.llvm.org/D37436 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
