[Issue 7198] Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198 --- Comment #1 from Kenji Hara 2012-01-02 05:35:59 PST --- > 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: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198 Alex R�nne Petersen changed: What|Removed |Added CC||xtzgzo...@gmail.com --- Comment #2 from Alex R�nne Petersen 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: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198 --- Comment #3 from Alex R�nne Petersen 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: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198
Jacob Carlborg changed:
What|Removed |Added
CC||d...@me.com
--- Comment #4 from Jacob Carlborg 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: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198
--- Comment #5 from Alex R�nne Petersen 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: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198 --- Comment #6 from Rainer Schuetze 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: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198
--- Comment #7 from Jacob Carlborg 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: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198 --- Comment #8 from Kenji Hara 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: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198 Jesse Phillips changed: What|Removed |Added CC||jesse.k.phillip...@gmail.co ||m Target Milestone|--- |2.059 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198 yebblies changed: What|Removed |Added CC||yebbl...@gmail.com Platform|Other |All OS/Version|Windows |All Severity|regression |normal --- Comment #9 from yebblies 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: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198 Kenji Hara changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #10 from Kenji Hara 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: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
http://d.puremagic.com/issues/show_bug.cgi?id=7198
--- Comment #11 from Andrej Mitrovic 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: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
https://d.puremagic.com/issues/show_bug.cgi?id=7198 yebblies changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #12 from yebblies 2013-11-27 18:04:25 EST --- This was intentional, as stated in other comments. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7198] Delegate literals with nameless arguments fail to infer a type
https://issues.dlang.org/show_bug.cgi?id=7198 Andrei Alexandrescu changed: What|Removed |Added Target Milestone|2.059 |--- Mathias LANG changed: What|Removed |Added CC||pro.mathias.l...@gmail.com --- Comment #13 from Mathias LANG --- 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. --
