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



More information about the Digitalmars-d mailing list