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

[Michel Fortin]

On 2010-02-25 14:11:02 -0500, Don <nospam at nospam.com> said:

> Michel Fortin wrote:
>> To me, an attribute should be seen like this:
>> 
>> """
>> If something is an attribute, then it's accessory to the language. 
>> Something is accessory when you can remove it completely from a program 
>> and expect the program to compile and behave the same. Attributes are 
>> not changing anything beside adding some restrictions to improve 
>> safety, optimization, etc.
>> """
> 
> Please. *I* invented that rule.

I did not claim I invented it, just that this is what I think should be 
an attribute. It's very possible I was influenced by your previous 
posts into thinking this, but I'm not always tracking perfectly where 
each of my opinions come from. Sorry if I overexplained everything to 
you.

I quite agree that having pure as @pure and nothrow as @nothrow would 
be better than nothing.

If you want a rationale that works for everything beside pure and 
nothrow, I think it'd work better to just say that new keywords added 
in version 2 of D that behave as attributes(*) use the @attribute 
syntax. If pure and nothrow stay like this, just add a cutoff date to 
the above.

(*): http://www.digitalmars.com/d/2.0/attribute.html

I know you're trying to avoid this kind of "historical incident" kind 
of rule, but making a rule that depends instead on the history of 
C-derived languages doesn't really improve things in my opinion. Keep 
in mind that the state of "other C-derived languages" is both vague and 
moving target; D1 isn't.

Also, a rule that depends on compile-time reflection special cases 
means that you have to explain compile-time reflection to those who ask 
you what the rule is. Most of the time when explaining to someone 
you'll choose to say it's arbitrary or historical rather than using a 
too complex rule.

If you're trying to push a rule to simplify the implementation of 
compile-time reflection, then that's fine. But to me trying to make a 
rationale that work for @property while disregarding history is just 
like interpolating coordinates from unrelated data sets.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/