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.