C++11 attributes for C11 (was Re: [PATCH] Generalized attribute support)

[Richard Smith]

On Mon, Apr 21, 2014 at 2:04 PM, Aaron Ballman <aaron at aaronballman.com>wrote:

> On Sat, Apr 19, 2014 at 7:05 PM, Alp Toker <alp at nuanti.com> wrote:
> > Small update for the list..
> >
> > We discussed this at LLVM Europe 2014 and came to the conclusion that we
> > might as well offer the feature behind an -f flag.
> >
> > This should satisfy user requests for C++11-style attributes in C11
> without
> > prejudicing any standards process.
>
> Why just C11? If we're using a feature flag, wouldn't it make sense to
> expose this for C++98, or C99, or ObjC (presuming there are no
> ambiguities)?


Yes, if we have this, it should work in all language modes unless there's
some fundamental incompatibility.


> > Thanks to the many detailed use-cases
> > people sent in that have made me more comfortable picking this up again.
> >
> > So, I've got a slightly improved version of the patch and will aim to
> rebase
> > and post it to the list for review in the coming weeks.
> >
> > All we need now is great name for the -f flag ;-)
>
> I like my bikesheds to be blue!
>
> -fcxx-style-attributes
> -fcxx-attributes
>
> I don't have a strong opinion on the name, but I do think that the
> feature flag should warn in nonsense situations (for instance
> -fno-cxx-attributes -std=c++11), or maybe even -fcxx-attributes
> -std=c++11 (since it's redundant, but I'm less tied to this).
>

-fc++-attributes? We already have +s in -W and -std flags, why not in a -f
flag? =)

I don't see any particular reason to disallow or warn about -std=c++11
-fno-c++-attributes, even though I don't immediately see a good reason to
use that flag combination. We should allow -std=c++11 -fc++-attributes, so
that software that compiles with or without c++11 but needs c++ attributes
can use 'clang $std -fc++-attributes'.

I think the only remaining argument against this is that we've historically
tried to avoid creating language dialects by allowing some language
features but not others. We've seen the damage done to C and C++ by GNU
extensions, and we want to avoid doing the same thing ourselves. The
counterpoint is that the alternative (__attribute__) in this case is
already a language extension.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140421/c4a3dfc9/attachment.html>