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

[Jonathan M Davis]

Don wrote:

> 
> I genuinely thought @pure, @nothrow was a no-brainer.
> 
> I really thought the explanation that "we made all attibutes use the @
> form, except those where it was prevented by historical precedent" was
> quite defensible.
> 
> But I was very, very wrong. Looks like the community is giving a massive
> vote for complete unpredictability.
> 
> <Throws hands in air />

Pick what you're going to pick. Personally, I have no problem with 
historical precedent. Changing public or private to be attributes would be 
quite disconcerting given how C++, Java, C#, D1, etc. all have them as 
keywords. And making them attributes would make porting code that much 
harder. It seems entirely valid to me.

However, in the end, they are what they are and we just get to deal with it. 
Personally, I'd expect attributes to be more reflection-centric (as in 
potentially checked at runtime, though D's runtime reflection is currently 
lacking) and keywords to be more compile-time centric. I tend to think of 
attributes as being addons to the language rather than directly a part of 
it. So, either they're user-defined (which I don't think we can do in D 
yet), or they're the kind of thing which would result in giving compiler 
warnings, or allowing it to do some additional stuff, but aren't really a 
key part of the language. However, under that rational, I'd probably end up 
making most of the items currently up for discussion keywords rather than 
attributes.

Regardless of why you choose to make a particular modifier an attribute or a 
keyword, there are going to be reasons to disagree. I don't think that it's 
quite as subjective as picking function names, but it's still pretty 
subjective. So, I don't think that worrying over the reasons for it is going 
to help much.

Personally, I say pick the keywords such that it minimizes how much code 
will have to change - ported or otherwise. I think that historical reasons 
is a fine reason for choosing which way to go with a particular word. It's 
arbitrary enough already, so just minimize how much has to be changed. And 
when it comes down to it, we'll just have to deal with it however it is. If 
it's an attribute, we'll use it as an attribute. If it's a keyword, we'll 
use it as a keyword. In the end, I don't think that it matters all that much 
when it comes to new code. But at least historical reasons would limit the 
amount of code that would have to be changed.

- Jonathan M Davis