Seeking a Syntax for Attributes in C++09

Document Number: n2224(07-0084)
2007-03-12
Alisdair Meredith <alisdair.meredith@uk.renaultf1.com>

Motivation

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

n2108 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 polymorphic.

n2117 Dynamic libraries

There is already much existing practice using a declspec-like syntax to control visibility of functions in dynamic libraries.

n2129 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.

n2147 Thread local storage

An attribute would be a fairly clean way to mark an object with thread storage duration.

n2165 Controlling alignment

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.

n2172 PODs Revisitted

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.

n2210 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

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 ( n1866)

The future

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 feature.