Leandro Lucarella wrote:
Don, el 25 de febrero a las 03:32 me escribiste:
We'll need compile-time reflection for all attributes. This can lead
us to a rationale for which attributes are keywords, and which are
@attributes.
For @ attributes, we can have a syntax vaguely like:
__traits(hasAttribute, "safe", foo);
The details aren't important, but it seems clear that we'll need
some such thing.
Anything which isn't an @ attribute will need to have its own traits
support. We want to minimize the number of such special cases.
Here are some rules.
* If it exists as a keyword in C++, it is not an @attribute.
* hasAttribute is never used for identifying conditional compilation.
* If accessing it via a standard hasAttribute syntax will reduce the
number of reflection special cases, it should have an @ prefix.
Note that some attributes, though not keywords in C++, are
intimately tied to other features which are C++ keywords. So the
combination of rule 1 + rule 3 stops them from being @ attributes.
I know these rules are a little ad-hoc, and aren't as unambiguous as
we might hope, but I think they do give us the consequences that we
want. Importantly, it lets @property continue as an attribute.
I think this is really silly. Inventing a set of wicked rules just to
match an arbitrary decision is really worse than accepting that arbitrary
decision per se. Now you have to remember some complicated rules to try to
make sense of something that doesn't make sense in the first place.
The only rule that makes a little sense for me is 2), but I don't even
agree with the deprecated case, deprecated is both version(deprecated)
*and* issuing a warning, and gives you information about the function that
you might want to know via reflection.
If you want safe, trusted, system, property, pure and nothrow as
attributes but not private, protected, public, package and deprecated,
I think it's better to say that than inventing some weird ad-hoc rules.
I genuinely thought @pure, @nothrow was a no-brainer.
I really thought the explanation that "we made all attibutes use the @
form, except those where it was prevented by historical precedent" was
quite defensible.
But I was very, very wrong. Looks like the community is giving a massive
vote for complete unpredictability.
<Throws hands in air />