Should pure nothrow ---> @pure @nothrow ?

[Don]

Ary Borenszweig wrote:
> Don wrote:
>> #ponce wrote:
>>>> Definitely. And what about @deprecated and @override?
>>>
>>> As override is now required, i don't think it should be an attribute.
>>
>> As I understand it, one of the characteristics of attributes is that 
>> you should be able to remove them from the entire program, without 
>> affecting the behaviour.
> 
> This is not correct. For example in C# you have the Flags attribute for 
> enums:
> 
> enum Foo {
>   One = 1,
>   Two = 2,
>   Three = 4,
> }
> 
> You can't do:
> 
> var x = Foo.One | Foo.Two;
> 
> but if you do:
> 
> [Flags]
> enum Foo { ... }
> 
> you can do it now.
> 
> Also see this: 
> http://msdn.microsoft.com/en-us/library/system.flagsattribute(VS.71).aspx
> 
> Removing the Flags attribute changes program behaviour. An attribute, 
> indeed, tells someone (the compiler, the programmer, an external tool) 
> that a symbol has some attribute. It could change the program if the 
> compiler is the one using that attribute. So in theory every attribute 
> in D could be an @attribute.

Interesting. I think if we go to that extreme, the annotations would 
just end up being keywords, but slightly uglier.
It seems clear that if @safe is an annotation, then @pure and @nothrow 
are, too.

I also think that the huge body of C++, Java, C# (and even D!) code sets 
a precedent that public, protected, extern, and private should not be 
annotations -- I'd suggest that if it is a keyword in C or C++, it 
should not be an annotation. (Although that would make align a keyword, 
not an annotation, though it'd otherwise be a candidate).

Beyond that, I'm not really sure. I'd tentatively go for @deprecated, 
and @property seems to have been decided, but for override -- no idea.