www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Implicit delegate conversions

reply Tomek =?ISO-8859-2?Q?Sowi=F1ski?= <just ask.me> writes:
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


Jan 15 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Jan 15 2011
parent reply Tomek =?ISO-8859-2?Q?Sowi=F1ski?= <just ask.me> writes:
Steven Schveighoffer napisa=B3:

 I think this is one place where D can improve by vast amounts without a =
=20
 lot of effort (no change in code generation, just in implicit casting).  =
=20 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 =
=20
 contravariant delegates (which was denied by Walter).
Why was it denied? (or just point me to the bug, pls) --=20 Tomek
Jan 17 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Jan 19 2011