hfinkel added a comment. 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? 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). 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. https://reviews.llvm.org/D37436 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
