Comment #0 by bearophile_hugs — 2010-02-18T13:15:09Z
override attribute is better to become obligatory (even when no -w is used) as in C#, to avoid mistakes like this:
import std.stdio;
class Dog {
public static void bark() {
writeln("woof ");
}
}
class Basenji : Dog {
public static void bark() {}
}
void main() {
Dog woofer = new Dog();
Dog nipper = new Basenji();
woofer.bark();
nipper.bark();
}
If the programmer knows that override is present if and only if a method override another one, then this code can't be ambiguous.
(I think in C++ the obligatory override attribute is less necessary because methods are not virtual by default, so only if you add an explicit "virtual" a method can be overriden).
Comment #1 by issues.dlang — 2011-03-22T18:16:39Z
override is obligatory according to TDPL.
Comment #2 by bearophile_hugs — 2011-04-26T04:26:24Z
How do you compile this with "-w" (warnings on) (reduced from code by Benjamin Thaut)?
class Foo(T, R...) : Foo!R {
void bar() {
super.bar();
}
}
class Foo(T){
void bar() {}
}
void main() {
new Foo!(int, float)();
}
Comment #3 by issues.dlang — 2011-04-26T09:31:26Z
You add override to the subclass' bar function's signature.
Comment #4 by bearophile_hugs — 2011-04-26T10:10:36Z
(In reply to comment #3)
> You add override to the subclass' bar function's signature.
Do you want to show me the code that compiles with -w?
Comment #5 by issues.dlang — 2011-04-26T10:25:50Z
class Foo(T, R...) : Foo!R {
override void bar() {
super.bar();
}
}
class Foo(T){
void bar() {}
}
void main() {
new Foo!(int, float)();
}
I don't see what's so confusing about that. Per -w (and per TDPL) any time that you override a function, you need to put the override attribute on the version in the subclass.
Comment #6 by bearophile_hugs — 2011-04-26T10:27:29Z
I was about to write an answer like yours, sorry :-)
The reason this is marked as a warning is to not break existing code without providing a long transition period for users. The next step will be to make it deprecated, and then an error.
I'll merge all the test case patches, but not the func.c change.
Comment #9 by bearophile_hugs — 2011-10-09T13:31:58Z
(In reply to comment #8)
> The reason this is marked as a warning is to not break existing code without
> providing a long transition period for users. The next step will be to make it
> deprecated, and then an error.
>
> I'll merge all the test case patches, but not the func.c change.
I understand. It will take a year or more.
http://dlang.org/hijack.html
"The D solution is straightforward. If a function in a derived class overrides a function in a base class, it must use the storage class override. If it overrides without using the override storage class it's an error. If it uses the override storage class without overriding anything, it's an error."
Though I'm not sure the term "storage class" is correct here. And there's no mention of obligatory override on attribute.html.
Comment #12 by github-bugzilla — 2012-09-25T06:12:56Z