A rationale for pure nothrow ---> @pure @nothrow (and nothing else changes)

Don 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 
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++.
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.

pure, nothrow:
Yes. These should change.

More information about the Digitalmars-d mailing list