A rationale for pure nothrow ---> @pure @nothrow (and nothing else changes)
nospam at nospam.com
Wed Feb 24 18:32:57 PST 2010
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
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++.
No. Tied to the other protection classes. Once the others are out, we
don't benefit from hasAttribute syntax for the last survivor.
No. This is equivalent to version(deprecated), but with better error
messages. Not an attribute.
No. keyword in C++.
No. Tied to virtual.
safe, trusted, system:
Yes. We can avoid a reflection special case.
Yes. These should change.
More information about the Digitalmars-d