digitalmars.D.bugs - [Issue 7198] New: Delegate literals with nameless arguments fail to infer a type
- d-bugmail puremagic.com Jan 02 2012
- d-bugmail puremagic.com Jan 02 2012
- d-bugmail puremagic.com Jan 02 2012
- d-bugmail puremagic.com Jan 02 2012
- d-bugmail puremagic.com Jan 02 2012
- d-bugmail puremagic.com Jan 02 2012
- d-bugmail puremagic.com Jan 02 2012
- d-bugmail puremagic.com Jan 02 2012
- d-bugmail puremagic.com Jan 02 2012
- d-bugmail puremagic.com Jan 19 2012
- d-bugmail puremagic.com Jan 31 2012
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 --- Comment #0 from Rainer Schuetze <r.sagitario gmx.de> 2012-01-02 05:07:52 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
d-bugmail puremagic.com http://d.puremagic.com/issues/show_bug.cgi?id=7198 --- Comment #1 from Kenji Hara <k.hara.pg gmail.com> 2012-01-02 05:35:59 PST ---I guess the trouble is that the delegate argument "Widget" is interpreted as a
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 --- Comment #2 from Alex Rønne Petersen <xtzgzorex gmail.com> 2012-01-02 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 --- Comment #3 from Alex Rønne Petersen <xtzgzorex gmail.com> 2012-01-02 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 --- Comment #4 from Jacob Carlborg <doob me.com> 2012-01-02 06:35:27 PST --- (In reply to comment #3)(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 --- Comment #5 from Alex Rønne Petersen <xtzgzorex gmail.com> 2012-01-02 06:41:35 PST --- (In reply to comment #4)(In reply to comment #3)(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
http://d.puremagic.com/issues/show_bug.cgi?id=7198 --- Comment #6 from Rainer Schuetze <r.sagitario gmx.de> 2012-01-02 07:44:36 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=7198 --- Comment #7 from Jacob Carlborg <doob me.com> 2012-01-02 09:09:00 PST --- (In reply to comment #5)(In reply to comment #4)(In reply to comment #3)(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
http://d.puremagic.com/issues/show_bug.cgi?id=7198 --- Comment #8 from Kenji Hara <k.hara.pg gmail.com> 2012-01-02 16:59:46 PST --- (In reply to comment #6)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
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 --- 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: -------
Jan 31 2012