digitalmars.D.bugs - [Issue 7198] New: Delegate literals with nameless arguments fail to infer a type
- d-bugmail puremagic.com (37/37) Jan 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7198
- d-bugmail puremagic.com (12/13) Jan 02 2012 parameter name, not the type. Using "int" instead of "Widget" compiles.
- d-bugmail puremagic.com (12/12) Jan 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7198
- d-bugmail puremagic.com (9/9) Jan 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7198
- d-bugmail puremagic.com (25/29) Jan 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7198
- d-bugmail puremagic.com (12/42) Jan 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7198
- d-bugmail puremagic.com (10/10) Jan 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7198
- d-bugmail puremagic.com (12/53) Jan 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7198
- d-bugmail puremagic.com (7/14) Jan 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7198
- d-bugmail puremagic.com (10/10) Jan 19 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7198
- d-bugmail puremagic.com (14/14) Jan 31 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7198
- d-bugmail puremagic.com (10/10) Aug 06 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7198
- d-bugmail puremagic.com (32/43) Aug 06 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7198
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
http://d.puremagic.com/issues/show_bug.cgi?id=7198I guess the trouble is that the delegate argument "Widget" is interpreted as aparameter 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
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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=7198 06:41:35 PST ---But that's a type signature, not a literal.(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);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
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
http://d.puremagic.com/issues/show_bug.cgi?id=7198Oh, yeah, right.But that's a type signature, not a literal.(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;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.* 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.That will only work for one argument.* 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.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: -------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.
Jan 02 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7198Ok, 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
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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=7198 17:44:35 PDT ---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: -------I guess the trouble is that the delegate argument "Widget" is interpreted as aparameter 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.
Aug 06 2013