Ary Borenszweig 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.
This is not correct. For example in C# you have the Flags attribute for
enums:
enum Foo {
One = 1,
Two = 2,
Three = 4,
}
You can't do:
var x = Foo.One | Foo.Two;
but if you do:
[Flags]
enum Foo { ... }
you can do it now.
Also see this:
http://msdn.microsoft.com/en-us/library/system.flagsattribute(VS.71).aspx
Removing the Flags attribute changes program behaviour. An attribute,
indeed, tells someone (the compiler, the programmer, an external tool)
that a symbol has some attribute. It could change the program if the
compiler is the one using that attribute. So in theory every attribute
in D could be an @attribute.
Interesting. I think if we go to that extreme, the annotations would
just end up being keywords, but slightly uglier.
It seems clear that if @safe is an annotation, then @pure and @nothrow
are, too.
I also think that the huge body of C++, Java, C# (and even D!) code sets
a precedent that public, protected, extern, and private should not be
annotations -- I'd suggest that if it is a keyword in C or C++, it
should not be an annotation. (Although that would make align a keyword,
not an annotation, though it'd otherwise be a candidate).
Beyond that, I'm not really sure. I'd tentatively go for @deprecated,
and @property seems to have been decided, but for override -- no idea.
