LOOKUP_TABLE[0] = Method("method1", &Component.method1);
         LOOKUP_TABLE[1] = Method("method2", &Component.method2);

These two lines are weird.  ``pragma(msg)`` shows that type of
``&method1`` is ``void function()`` while it must be ``void delegate()``
for a non-static member because of difference in calling convention.
Actually I think that taking an address of a non-static member in a
static context must be a compile time error.

It's because I'm taking the address of the function on the type, not on an instance. It's not a delegate because there's no "this" pointer yet.

It makes sense to me anyways. A delegate is a normal function pointer coupled with a hidden context parameter.

But you can't call that function pointer. Actually, you can probably subvert type safety, because functions have a different calling conventions from delegates. This also means that SafeD should disallow taking the address of methods from a type (without instance).

That's really silly. A nicer way would be to make &Type.method return a delegate with ptr set to null. Then calling this delegate would result in a (harmless) null pointer exception.

But even then, there's no safe way to construct a real delegate out of the method pointer. You can't simply assign an object instance to ptr, because you can't statically know if the funcptr of the delegate really is a method of that object instance.

Looks like SafeD proves to be unfeasible again.

Reply via email to