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