A rationale for pure nothrow ---> @pure @nothrow (and nothing else changes)
Don
nospam at nospam.com
Thu Feb 25 22:06:09 PST 2010
Michel Fortin wrote:
> 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.
The point is that it's been previously discussed, and it doesn't work.
> 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.
You could say that. It's pretty much the same as the list from 'C-family
languages'. we don't care about backwards compatibility with keywords
from D1.
> If pure and nothrow stay like this, just add a cutoff date to the above.
That isn't any better than an arbitrary list.
> (*): 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.
No, I'm trying to avoid a "prehistorical accident" type of rule.
For these purposes, the history of D begins when TDPL is published.
We're still in prehistory for a few more weeks.
Compatibility with C and C++ has always been critical for D; D contains
many historical accidents from C. But D has not yet set any historical
precedents.
If we simultaneously release a language with @attributes, together with
attributes that don't use them, it looks silly.
More information about the Digitalmars-d
mailing list