On 2010-02-25 14:11:02 -0500, Don <[email protected]> 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
[email protected]
http://michelf.com/
