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

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

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

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

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

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

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

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

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

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