On 14/01/2014 03:10, Richard Smith wrote:
On Mon, Jan 13, 2014 at 6:37 PM, Aaron Ballman <[email protected]
<mailto:[email protected]>> wrote:
On Mon, Jan 13, 2014 at 9:24 PM, Richard Smith
<[email protected] <mailto:[email protected]>> wrote:
> On Sun, Jan 12, 2014 at 11:14 AM, Aaron Ballman
<[email protected] <mailto:[email protected]>>
> wrote:
>>
>> After doing a bit more research and discussion off-list, I think
>> "generalized attribute" is acceptable. So patch LGTM as-is.
>
>
> Really? I wouldn't expect someone seeing this diagnostic to
understand that
> "generalized attribute" means C++11 attributes (it's a really
weird term,
> since they're not a generalization of anything). This isn't an
official name
> for them, and doesn't distinguish them from the other attribute
syntaxes we
> support. Given that this is a diagnostic about compatibility
with C++98,
> "C++11 attributes" seems like the clearest way of expressing this.
As Alp had pointed out, we document the name as "generalized
attribute" in our feature support documentation,
You're right, we did. I just fixed that.
and it's the original name of the feature.
[citation needed]
The proposal calls them "General Attributes for C++" (and all previous
revisions of it did the same); the word "Generalized" seems to have
been accidentally transferred from "Generalized constant expressions"
in the GCC list, and we inherited that mistake when we sync'd our list
with theirs in r142015. The paper and C++ standard both call them
simply "attributes".
Also, a quick google search of "generalized
attribute" yielded more results than "C++11 attribute" did (not saying
this was particularly scientific). So that's why I gave the LGTM on
the term.
Hah, it seems that lots of people copied our C++11 feature list and
GCC's, picking up the wrong name =)
It may be a typo, but the C++ community has clearly adopted the name
"generalized attributes".
I think we should take it and run with it :-)
Reasons to do so:
* "C++11 attributes" don't work as a feature name when bringing this
to C11 as an extension or enabling it in proposed next-generation
OpenMP modes. It'd be bizarre to diagnose with "C++11 attribute ..."
in C11.
* It feels old keeping the version of introduction in the name. We
don't do this with other features that have been published, why
introduce a special-case "C++11 attributes"?
* Leaving the name as just "attributes" is ambiguous in this context
because users have got used to "attributes" referring to the GNU form.
Alp.
That being said, my original preference was for C++11 attribute
instead, and as you point out, this is a C++98 compat diagnostic, so
using "C++11" would be clear. Perhaps I should have stuck with my gut
instead. ;-)
~Aaron
--
http://www.nuanti.com
the browser experts
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
