www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 7198] New: Delegate literals with nameless arguments fail to infer a type

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7198

           Summary: Delegate literals with nameless arguments fail to
                    infer a type
           Product: D
           Version: D2
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Keywords: rejects-valid
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: r.sagitario gmx.de



PST ---
Maybe this is an expected side-effect of more magic with delegate type
inference, but the latest dmd version from github causes errors with this code:

module test;

class Widget {}

void main()
{
    auto dg0 = delegate void(Widget w) { };  // OK
    auto dg1 = delegate void(Widget) { };  // error
    void delegate(Widget) dg2 = delegate void(Widget) { }; //OK
    void delegate(Widget) dg3;
    dg3 = delegate void(Widget) { foo(); }; //error
}

test.d(8): Error: cannot infer type from ambiguous function literal
__dgliteral2
test.d(8): Error: __dgliteral2 has no value
test.d(11): Error: __dgliteral6 has no value

This compiles with dmd 2.057.

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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 02 2012
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7198





 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 02 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7198


Alex Rønne Petersen <xtzgzorex gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xtzgzorex gmail.com



05:40:07 PST ---
Why not just disallow unnamed parameters entirely? Seems like cleaner language
design to me. What we have now is clearly ambiguous and cannot be resolved,
so...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 02 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7198




05:46:26 PST ---
(I don't actually know why we have unnamed parameters at all; most modern
languages simply don't allow this. In addition, unused parameters in
delegate/function literals/lambdas sort of seems to go against the entire idea
with lambda functions, in the general case.)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 02 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7198


Jacob Carlborg <doob me.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doob me.com





 (I don't actually know why we have unnamed parameters at all; most modern
 languages simply don't allow this. In addition, unused parameters in
 delegate/function literals/lambdas sort of seems to go against the entire idea
 with lambda functions, in the general case.)


Useful situations for unnamed parameters:

* Declaring a delegate type

void delegate (int) dg;

* Declaring a function/method without implementation

void foo (int);

* Overriding/implementing a method where a parameter isn't needed

class Foo {
    abstract void foo (int a);
}

class Bar : Foo {
    void foo (int) {}
}


These are the situations I see it as might being useful but I would say that
adding names to the parameters adds documentation and that's always a good
thing.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 02 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7198




06:41:35 PST ---




 (I don't actually know why we have unnamed parameters at all; most modern
 languages simply don't allow this. In addition, unused parameters in
 delegate/function literals/lambdas sort of seems to go against the entire idea
 with lambda functions, in the general case.)


 
 Useful situations for unnamed parameters:
 
 * Declaring a delegate type
 
 void delegate (int) dg;


But that's a type signature, not a literal.


 
 * Declaring a function/method without implementation
 
 void foo (int);


This, on the other hand, I do not like. Without a parameter name, you have to
look at the implementation to have a clue what it means. That makes the
declaration (more or less) useless.


 
 * Overriding/implementing a method where a parameter isn't needed
 
 class Foo {
     abstract void foo (int a);
 }
 
 class Bar : Foo {
     void foo (int) {}
 }
 


Point taken, though naming it _ or similar usually works.


 
 These are the situations I see it as might being useful but I would say that
 adding names to the parameters adds documentation and that's always a good
 thing.


Agreed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 02 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7198




PST ---
Ok, I understand.

There are already a number of situation where the decision Type/Variable is
deferred to the semantic phase. Would it be possible to do the same here?

If not, I think the same syntax for delegate literals should be forbidden for
built-in types for consistency.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 02 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7198










 (I don't actually know why we have unnamed parameters at all; most modern
 languages simply don't allow this. In addition, unused parameters in
 delegate/function literals/lambdas sort of seems to go against the entire idea
 with lambda functions, in the general case.)


 
 Useful situations for unnamed parameters:
 
 * Declaring a delegate type
 
 void delegate (int) dg;


 
 But that's a type signature, not a literal.


Oh, yeah, right.


 
 * Declaring a function/method without implementation
 
 void foo (int);


 
 This, on the other hand, I do not like. Without a parameter name, you have to
 look at the implementation to have a clue what it means. That makes the
 declaration (more or less) useless.


I've seen it a lot when declaring C functions. There won't be an implementation
(at least not in your code) and you're relying on the documentation for the C
library.


 
 * Overriding/implementing a method where a parameter isn't needed
 
 class Foo {
     abstract void foo (int a);
 }
 
 class Bar : Foo {
     void foo (int) {}
 }
 


 
 Point taken, though naming it _ or similar usually works.


That will only work for one argument.


 
 These are the situations I see it as might being useful but I would say that
 adding names to the parameters adds documentation and that's always a good
 thing.


 
 Agreed.


Note that I'm not against this idea. Just pointing out how/when it can be used.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 02 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7198






 Ok, I understand.
 
 There are already a number of situation where the decision Type/Variable is
 deferred to the semantic phase. Would it be possible to do the same here?
 
 If not, I think the same syntax for delegate literals should be forbidden for
 built-in types for consistency.


It's a small, but good improvement for consistent. I'll post a patch to fix it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 02 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7198


Jesse Phillips <Jesse.K.Phillips+D gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Jesse.K.Phillips+D gmail.co
                   |                            |m
   Target Milestone|---                         |2.059


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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



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: -------
Jan 31 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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



---
*** 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: -------
Aug 06 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7198




17:44:35 PDT ---


 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: -------
Aug 06 2013