On Fri, 27 Nov 2009 12:30:30 +0300, Lars T. Kyllingstad
<pub...@kyllingen.nospamnet> wrote:
Denis Koroskin wrote:
On Fri, 27 Nov 2009 12:09:05 +0300, Don <nos...@nospam.com> 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).
So @deprecated is definitely an attribute.
Is override really required? I've just tested on DMD2.037, and it
still accepts functions without it. So at present it is behaving like
an attribute. But if it became mandatory, I'm not so sure.
override is required when compiling with -w.
By Walter's definition, @property is not a valid attribute, because by
removing it the program will fail to compile (due to missing parens in
accessors). Either that or omissible empty parens will still be
present, but I see no usefulness of @property in that case.
But it still doesn't affect the generated binary code, and I think
that's the important part here.
@property void foo(int i) { ... }
foo = 7;
generates the exact same code as
void foo(int i) { ... }
foo(7);
We need a definition of attributes/annotations that is a bit wider than
"can be removed from program without anything happening". Denis' example
clearly demonstrates this.
Something in the vein of "annotations only provide additional
information and constraints for the compiler, and do not affect the
generated code" would be better.
-Lars
I think "do not affect the generated code" is a bit restricting. I see
attributes as hints to compiler (especially since there is no way to use
user-defined attributes). Compiler may understand and make use of some of
them. For example, I'd like to be able to annotate a function as
@thread-safe, and hope that a smart compiler will optimize my code based
on that information (it doesn't mean it have to). Other example is that
I'd like for some functions to leave all bounds checks (even in -release)
without making it @safe. Or profile this concrete method. Or exclude this
concrete method from profiling. There are endless possibilities.
Some of this attributes might be vendor-specific, they should probably
start with a double-underscore (e.g. @__naked).
That's the way I see attributes.
