http://d.puremagic.com/issues/show_bug.cgi?id=4136

           Summary: @disable semantics
           Product: D
           Version: unspecified
          Platform: x86
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: bearophile_hugs@eml.cc


--- Comment #0 from bearophile_hugs@eml.cc 2010-04-30 17:34:06 PDT ---
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?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4136


Michal Minich <michal.minich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |michal.minich@gmail.com


--- Comment #1 from Michal Minich <michal.minich@gmail.com> 2013-06-18 04:20:48 PDT ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4136


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


--- Comment #2 from bearophile_hugs@eml.cc 2013-06-18 05:07:29 PDT ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------