Don wrote:
Lars T. Kyllingstad wrote:
Don wrote:
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
As I understand it, one of the characteristics of attributes is that
you should be able to remove them from the entire program, without
affecting the behaviour. All they are doing is adding additional
compile-time constraints. (const and immutable aren't attributes,
because you're allowed to overload functions based on them).
If this is the rule, shouldn't the protection attributes be moved into
the annotation namespace as well? (@private, @protected, @package,
@public) Since everything is public by default in D, a program will
keep working even if you remove them.
NOTE: I don't necessarily think they should, but I do think there
should be a definite rule for which attributes are @annotations and
which aren't. Otherwise it just seems random.
-Lars
Obviously my rule isn't correct. It's hard to come up with a rule that
includes @property, without including everything else.
That's what I suspected. How about saying that annotations only provide
compile-time constraints on the body, i.e. the internals, of the
function being annotated?
Then, the following would be annotations:
@safe, @unsafe, @system, @pure, @nothrow
while the following would have to be ordinary keywords:
property, private, public, deprecated
-Lars