On Sat, 15 Jan 2011 06:37:48 -0500, Tomek Sowiński <j...@ask.me> wrote:
The profusion of D's attributes has made delegate signature mismatches
all too likely thus one must resort to casts too often with e.g.
callbacks.
const(short)[] delegate(immutable(int)*) dg1;
immutable(short)[] delegate(const(int)*) pure nothrow @safe dg2;
dg1 = dg2; // fails (if *any* of storage classes or types don't match)
This problem is nothing new. It has been popping up in discussions and
bugzilla but was never addressed entirely.
The sketch of the conversion rules:
dg2 is implicitly convertible to dg1 if
- dg2 could override dg1 if they were class methods, bar polymorphic
return type covariance; OR
- each of d2's arguments is implicitly convertible from and binary
equivalent of dg1's respective argument and dg2's return type is
implicitly convertible to and binary equivalent of dg1's return type.
The overarching thought is that signature types of both delegates should
be indistinguishable in compiled binaries to rule out polymorphism** as
it involves vtable pointer shifting. In the type system, however, the
assigned delegate may have looser but compatible argument types (note:
overloading problems don't apply to delegates), a tighter return type,
or covariant attributes. The "if they were class methods" contortion is
my try to ease off the implementation -- some compiler code may be
reused (I may be wrong).
Please find holes.
I think this is one place where D can improve by vast amounts without a
lot of effort (no change in code generation, just in implicit casting).
I've brought this up, and contributed to one bugzilla report requesting
contravariant delegates (which was denied by Walter).
Hopefully you have more success.
-Steve