Thread overview
Implicit delegate conversions
Jan 15, 2011
Tomek Sowiński
Jan 17, 2011
Tomek Sowiński
January 15, 2011
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.

-- 
Tomek

** It works with C# delegates, though. Anyone knows how they do it?
January 15, 2011
On Sat, 15 Jan 2011 06:37:48 -0500, Tomek Sowiński <just@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
January 17, 2011
Steven Schveighoffer napisał:

> 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).

Yeah, my thoughts exactly. And bumping into a signature mismatch has gotten really likely.

> I've brought this up, and contributed to one bugzilla report requesting contravariant delegates (which was denied by Walter).

Why was it denied? (or just point me to the bug, pls)

-- 
Tomek

January 19, 2011
On Mon, 17 Jan 2011 14:39:02 -0500, Tomek Sowiński <just@ask.me> wrote:

> Steven Schveighoffer napisał:
>
>> 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).
>
> Yeah, my thoughts exactly. And bumping into a signature mismatch has gotten really likely.
>
>> I've brought this up, and contributed to one bugzilla report requesting
>> contravariant delegates (which was denied by Walter).
>
> Why was it denied? (or just point me to the bug, pls)
>

See the bug here:

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

There is also this (which is still open, maybe Walter hasn't seen it yet): http://d.puremagic.com/issues/show_bug.cgi?id=3180

-Steve