Comment #0 by bearophile_hugs — 2010-04-30T17:34:06Z
This is not yet a bug report, but it can become one.
This is D2 code:
class A {
void foo() {};
}
class B : A {
override @disable void foo() {}
}
class C : B {
override void foo() {};
}
void main() {
A b1 = new B;
b1.foo();
B c1 = new C;
c1.foo(); // Error: function test.B.foo is not callable...
}
It compiles with dmd 2.043 with an error:
test.d(15): Error: function test.B.foo is not callable because it is annotated with @disable
The b1 is an instance of class B, but the call to foo produces no error. While c1 is an instance of C, but it generates an error.
I don't understand well the design of @disable, but to be useful and more meaningful isn't it necessary/better to enforce it (at run-time) on the dynamic type of an object?
Comment #1 by michal.minich — 2013-06-18T04:20:48Z
(In reply to comment #0)
> I don't understand well the design of @disable, but to be useful and more
> meaningful isn't it necessary/better to enforce it (at run-time) on the dynamic
> type of an object?
@disable is exactly for static enforcement, so it can work on statically know type of variable (not dynamic instance type). Dynamic enforcement is available via "override void foo() { assert(false) };". So I think this bug is invalid.
Comment #2 by bearophile_hugs — 2013-06-18T05:07:29Z
(In reply to comment #1)
> @disable is exactly for static enforcement, so it can work on statically know
> type of variable (not dynamic instance type). Dynamic enforcement is available
> via "override void foo() { assert(false) };". So I think this bug is invalid.
Three years later I understand @disable better, and indeed this is invalid. Hopefully other D programmers will not make the same mistake of mine.