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

           Summary: Anonymous interface instantiation returned from
                    anonymous function misbehaves
           Product: D
           Version: D2
          Platform: x86
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: tim.m.shea@gmail.com


--- Comment #0 from Tim Shea <tim.m.shea@gmail.com> 2012-03-27 10:18:58 PDT ---
I asked about this issue on stackoverflow, thinking I had made a mistake. The
url is
http://stackoverflow.com/questions/9752414/why-do-i-need-opcmp-for-an-anonymous-class
and includes details on how and why I discovered the problem.

Using DMD on Windows, if I return an anonymous class derived directly from an interface from an anonymous function, the results are erratic and unpredictable. I believe this is because the vtbl layout is not consistent between the anonymous function creating the object and any clients of the object. An example:

interface TestInterface {
    string helloWorld();
}
class TestClass {
    abstract string helloWorld();
}

void invokeFn(TestInterface function() f) {
    auto t = f();
    auto s = t.helloWorld();
    writeln(s);
}

unittest {
    auto f = function() {
        return new class TestInterface {
            string helloWorld() {
                return "Hello World!";
            }
        };
    };
    // Invokes (f()).toString(), printing:
    // "src.utilities.testopcmp.__unittest2.__funcliteral1.__anonclass10"
    invokeFn(f);
}

void invokeFn(TestClass function() f) {
    auto t = f();
    auto s = t.helloWorld();
    writeln(s);
}

unittest {
    auto f = function() {
        return new class TestClass {
            string helloWorld() {
                return "Goodbye World!";
            }
        };
    };
    // Invokes (f()).helloWorld(), printing:
    // "Goodbye World!" as expected
    invokeFn(f);
}

This may be a minor bug in the compiler or in object.d? If so, then a fix would be appreciated. However, as abstract classes work correctly under the same circumstances, if the issue is that interfaces *should not* be anonymously instantiated (actually seems pretty reasonable) then that could be documented and the above code could throw an error. In that case, even if the interface is fixed, the anonymous function could probably declare a static nested abstract class, and inherit that class. Thanks!

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