We'll need compile-time reflection for all attributes. This can lead us
to a rationale for which attributes are keywords, and which are @attributes.
For @ attributes, we can have a syntax vaguely like:
__traits(hasAttribute, "safe", foo);
The details aren't important, but it seems clear that we'll need some
such thing.
Anything which isn't an @ attribute will need to have its own traits
support. We want to minimize the number of such special cases.
Here are some rules.
* If it exists as a keyword in C++, it is not an @attribute.
* hasAttribute is never used for identifying conditional compilation.
* If accessing it via a standard hasAttribute syntax will reduce the
number of reflection special cases, it should have an @ prefix.
Note that some attributes, though not keywords in C++, are intimately
tied to other features which are C++ keywords. So the combination of
rule 1 + rule 3 stops them from being @ attributes.
I know these rules are a little ad-hoc, and aren't as unambiguous as we
might hope, but I think they do give us the consequences that we want.
Importantly, it lets @property continue as an attribute.
---
Specific keywords which have been mentioned in the past:
private, protected, public:
No. Keywords in C++.
package:
No. Tied to the other protection classes. Once the others are out, we
don't benefit from hasAttribute syntax for the last survivor.
deprecated:
No. This is equivalent to version(deprecated), but with better error
messages. Not an attribute.
virtual:
No. keyword in C++.
override:
No. Tied to virtual.
safe, trusted, system:
Yes.
property:
Yes. We can avoid a reflection special case.
pure, nothrow:
Yes. These should change.
