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


yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies@gmail.com
           Platform|Other                       |All
         OS/Version|Windows                     |All
           Severity|regression                  |normal


--- Comment #9 from yebblies <yebblies@gmail.com> 2012-02-01 13:20:47 EST ---
Not a regression, but the result of a language change that happens to break some existing code.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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


Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich@gmail.com


--- Comment #10 from Kenji Hara <k.hara.pg@gmail.com> 2013-08-06 17:21:36 PDT ---
*** Issue 10767 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #11 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-08-06 17:44:35 PDT ---
(In reply to comment #1)
> > I guess the trouble is that the delegate argument "Widget" is interpreted as a
> parameter name, not the type. Using "int" instead of "Widget" compiles.
> 
> Yes, you're right.
> And that is inevitable side-effect of parameter type inference.
> 
> Walter answered about the decision in https://github.com/D-Programming-Language/dmd/pull/588 .
> 
> So this issue should be marked as 'resolved-invalid' or 'resolved-wontfix', IMO.

This is a bummer for code that deals with signals, e.g.:

signal.connect( (Widget widget, Event) {
    // ignores Event argument, but does something useful with a widget
});

If 'connect' is a function typed like so:

void connect(void function(Widget, Event)) { }

Then all works fine. However signals can typically take functions which do or don't return a value (functions with different return types), and signals can typically take both functions and delegates. So the connect method has to become a templated function which uses some traits and wraps this in a constraint, e.g.:

void connect(T)(T t) /* if (Constraint!T) */ { }

Even without the constraint this immediately fails at the call site due to this current Issue 7198.

I guess the only workaround is to use mixins to generate a number of connect methods, so they become:

void connect(void function(Widget, Event)) { }
void connect(void delegate(Widget, Event)) { }
void connect(bool function(Widget, Event)) { }
void connect(bool delegate(Widget, Event)) { }

And then type inference will work properly. It's far from ideal though, as you have to hardcode these combinations rather than allow arbitrary functions as signal handlers (e.g. functions with default parameters).

But what sucks the most is the standard template instantiation error, where the compiler tells you nothing about what went wrong.

But otherwise, I don't see a solution for this issue.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------