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

[Lars T. Kyllingstad]

Don wrote:
> 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.


I think this is the best proposal regarding this issue so far.  Is there 
still time to change this?

-Lars