Reader Q&A: Keywords and Attributes

C++ 1 Minute

Referring to C++ AMP, a reader emailed me to ask:

Are you going to replace restrict keyword with new C++11 attribute feature [[]] ?

No, because restrict is a language feature and [[attributes]] are specifically designed to be ignorable and shouldn’t be used for things having language semantic meaning. During the ISO C++11 process, I was heavily involved in a long battle to try to prevent keywords dressed in [[attributes]] clothing from sneaking into the standard; for example, C++11 final and override used to be [[final]] and [[override]] in pre-final* drafts and I led the charge against that, and with the help of likeminded people it was overturned.

 

* pun intended

Published by Herb Sutter

Herb Sutter is an author and speaker, a software architect at Microsoft, and chair of the ISO C++ standards committee.

Published

11 thoughts on “Reader Q&A: Keywords and Attributes”

  1. Pingback: Reader Q&A: What does it mean for [[attributes]] to affect language semantics? « Sutter’s Mill

  2. @Alf, @Herb – I don’t quite get the [[noreturn]] example. While it may (not) compile on VC++, (as far as I understand) it does not carry any semantic meaning, and, what’s more, it is *perfectly* safe for any compiler that sees [[noreturn]] to just ignore it — the runtime behaviour vs. VC++ shouldn’t be changed at all.

    So how is [[noreturn]] in the same camp as “restrict” ??? (I agree it may(?) be in the same camp as final and override.)

    I will quote Bjarne: (http://www2.research.att.com/~bs/C++0xFAQ.html#attributes)
    > There is a reasonable fear that attributes will be used to create language dialects.
    > The recommendation is to use attributes to only control things that do not affect the meaning
    > of a program but might help detect errors (e.g. [[noreturn]])
    > or help optimizers (e.g. [[carries_dependency]]).

    cheers,
    Martin

  3. Pingback: Reader Q&A: « Sutter’s Mill

  4. While you’re dealing with reader’s Qs….

    In your keynote in “Going Native” you mentioned that type inference should almost always be used, except for some obscure cases with expression templates.

    This seems like a rather serious wart on the language, part of the power of expression templates (to my understanding) is that they can be dropped in by a library implementer and thus improve the clients’ code without their knowledge.

    Was there any discussion to allow type authors to opt-out of type inference? (e.g. by allowing an “operator auto()”). If this wasn’t discussed for C++11 is it being discussed for C++1y?

    (For people reading this comment, if it doesn’t make any sense I wrote about it last year in my blog http://lanzkron.wordpress.com/2011/02/21/inferring-too-much/)

  5. Must seriously thank you, Herb.

    Final and override being attributes was initially the reason why I wouldn’t have used them, simply because I couldn’t trust them enough when designing classes and writing portable C++.

  8. @Herb: As someone who’s used MS’s “override” for a long time, I’m glad that you won that battle. As an aside, do you think the level of resistance to new keywords is justified? I find that joining two keywords together to give a new meaning (think “enum class” or “long long”) might have been better as new keywords. For example, it’s a little harder to search for all instances of “enum” that are not followed by “class”.

  9. @Herb: Well, considering that Clang doesn’t support attributes, GCC doesn’t support attributes, and Visual Studio doesn’t support attributes… I don’t think the standards people are going to be able to extend it much. If none of the major compilers support a feature, it’s not a real feature.

    Personally, I like the idea of having a generalized attribute syntax for these kinds of things; this would make doing certain #defines easier. But we should have had that in 98, not now. It’s too late now; we have too much divergence and too much code written that is able to pick from one to the other.

    And if GCC/Clang/VS aren’t going to convert their attributes over, then it’s worthless.

    Attributes are C++11’s “export”. Well, if user-defined literals aren’t…

  10. @Alf: Right, we didn’t win the war on [[attributes]] completely. But I *think* that’s the only one (there might have been one other) — we also won the battle against [[attributes]] for base_check and alignas alignment control.

    I actually argued hard and long to keep [[attributes]] out of the standard entirely, and won in C but not in C++. Briefly, the argument was on the grounds that it didn’t make sense to standardize a portable syntax for inherently nonportable constructs, and that the feaure was being voted in over the objections of the very same two vendors who were being cited as prior art (Microsoft and Gnu). But the main win is intact — the C standard doesn’t have attributes, and the C++ standard has them but mostly doesn’t have keywords dressed in [[attributes]] clothing, and now that attributes are in the standard we’ll just have an ongoing tax of effort to keep it way whenever new proposals to use them come up…

  11. Hm, [[noreturn]] is one that you didn’t manage to prevent. Depending on whether a function is marked as noreturn (via Visual C++ __declspec( noreturn )), code will compile, or not. So presumably that behavior will be the same when or if Visual C++ starts supporting standard [[noreturn]].

    Cheers,

    – Alf

Comments are closed.