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

[Don]

Leandro Lucarella wrote:
> Don, el 25 de febrero a las 03:32 me escribiste:
>> 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.
> 
> I think this is really silly. Inventing a set of wicked rules just to
> match an arbitrary decision is really worse than accepting that arbitrary
> decision per se. Now you have to remember some complicated rules to try to
> make sense of something that doesn't make sense in the first place.
> 
> The only rule that makes a little sense for me is 2), but I don't even
> agree with the deprecated case, deprecated is both version(deprecated)
> *and* issuing a warning, and gives you information about the function that
> you might want to know via reflection.
> 
> If you want safe, trusted, system, property, pure and nothrow as
> attributes but not private, protected, public, package and deprecated,
> I think it's better to say that than inventing some weird ad-hoc rules.

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 />