Seeking a Syntax for Attributes in C++09
Document Number: n2224(07-0084)
Alisdair Meredith <email@example.com>
The evolution of C++ faces a serious problem selecting new keywords.
This problem is confronted directly in Beman Dawes paper N2105, where
the risk of collision with existing users' names clearly restricts
our ability to select clear, descriptive keywords in the future. If
the term is simple and expressive, it is already in widespread use.
This limits us to obscure, hard to pronounce or write terms, or
obscure overloads of existing keywords. One day, every keyword
could have as many meanings as static!
This paper aims to illustrate the large number of existing proposals
running into this problem, and seeks to find a way to open up a
new namespace for keywords reserved to the implementers.
One avenue explorer by other languages has been stealing keywords
only in a specific context, where they would not have been meaningful
before. The context guarantees you are not stealing the name from
the users, at the expense of making the language harder to parse.
There is a clear precedent here in a C++ context with the ECMA C++/CLI
binding, which has employed the technique with reasonble success.
Another technique would be to introduce a new keyword whose only purpose
in life is open a new keyword namespace. Most implementations already
contain an extension that offers this sort of facility, often with the
name __declspec of __attribute__.
Without proposing a specific syntax ahead of the next EWG meeting, this
paper suggests it would be beneficial for the ease of passage of several
existing papers if such a mechanism was agreed, and an agreeable syntax
found. Finding a common solution and opening up the keyword namespace
(inside the attribute) would pay dividends many times over.
Note that while the author refers to a potential attribute being 'clean'
or aesthetically pleasing, beauty is always in the eye of the beholder
and sometimes there is no substitute for a real keyword, even if it is
obfuscated or overloaded. Below are a number of proposal that might
benefit from this direction - it is not necassary for all of them to
adopt this feature for it to be a success. Even a small number of hits
might move the language forward quickly and cheaply.
It is believed that there is active work on a syntax proposal elsewhere
on the committee, and there is hope that a formal proposal will be
available for the Oxford meeting, even if it misses this mailing.
Proposals that might benefit
Explicit syntax to override virtual functions
This paper has been provisionally accepted as ready for Core review,
but is blocked for the lack of a syntax to mark a class as explict
There is already much existing practice using a declspec-like syntax
to control visibility of functions in dynamic libraries.
User Controlled Garbage Collection
Attributes would avoid introducing a number of new keywords, as
required by this proposal, which was marked as a key deliverable
in the Registration Ballot.
Thread local storage
An attribute would be a fairly clean way to mark an object with thread
Early feedback from the Core Working Group was that this feature would be more cleanly
implemented as attributes, and it was hoped that EWG might arrive at an attribute
syntax before this passed through review. It is currently proceeding without.
Attributes would add a lot of value when revisitting the POD concepts.
Triviality and layout could be controlled with attributes, and
by declaring a class with the appropriate attribute, invalid class
designs can be checked by the compiler and flagged as errors.
Defaulted and Deleted Functions
Function accessibility/visibility could be controlled in this way,
avoiding the problems associated with the prohibited keyword paper
(n2123). Lawrence Crowl's proposal tackles this directly with an
overloaded syntax, but an attribute could work just as well.
core issue 13
A syntax for pointers to extern "C" functions
The key to this issue is there is no easy way to inject the extern into the syntax for a function pointer.
Attributes could easily plug the gap.
Further applications, not all targetting C++09, might include a cleaner
alternative to the enum class for strong enums (
n1719); support for strong typedefs (
n1891); declaration of pure side-effect free functions;
final overrides and sealed classes; fine grained control over concurrency;
support for runtime reflection; a lightweight support for contract programming (
Finally, establishing such a facility in C++09 greatly frees the
committee's ability to innovate in the next revision of the standard,
much less constrained by the need to acquire a new keyword for every