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

Don nospam at nospam.com
Thu Feb 25 11:11:02 PST 2010


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. It was appealing, but IT DOES NOT WORK. 
And it has been discussed to death. Forget it. Be aware of the state 
that the language is in right now. What I've proposed here is a 
last-ditch effort to improve the situation from 'completely random' with 
as little change as possible.

In previous discussions, the only thing everyone agreed on was that pure 
should be @pure, and nothrow should become @nothrow.

So I've come up with a rationale which changes those two, and retains 
the status quo on everything else. And I'm hoping that it's not too late 
to change those two.

Sure, the rationale is weak. But IMHO it's better than nothing, which is 
what we have now. And we're just about out of time.

To rephrase it: the rationale is that if it has a precedent as a keyword 
in C-family languages, it remains a keyword. If not, it uses @ syntax.

It means that instead of having situations where we say, "this is not an 
@attribute for historical reasons in the development of D", we instead 
say "this is not an @attribute, because of compatibility with C-family 
languages".

The point of bringing reflection into it was as a rationale that 
closely-related features stay together (eg, package behaves the same as 
private). You could probably come up with a stronger rationale for the 
same result. I'm basically saying that if we change pure, nothrow, it is 
*possible* to come up with an after-the-fact rationale. If we don't, the 
situation is hopeless.

And I don't really care if deprecated is an attribute or not. It's 
borderline; we probably get a more explainable result if it becomes 
@deprecated. But if pure, nothrow don't become @pure, @nothrow it's just 
random.



More information about the Digitalmars-d mailing list