Bug 7198 – Delegate literals with nameless arguments fail to infer a type

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.

> 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.

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...

(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.)

(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.

(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.

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.

(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.

(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.

Not a regression, but the result of a language change that happens to break some existing code.

*** Issue 10767 has been marked as a duplicate of this issue. ***

(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.

This was intentional, as stated in other comments.

Just hit this as I was about to report it as a bug. I came from this angle: https://github.com/dlang-community/D-Scanner/issues/846 So it was surprising, to say the least. And I don't think the grammar reflects this correctly.