www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3235] New: Function literals must be deduced as "function" or "delegate"

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3235

           Summary: Function literals must be deduced as "function" or
                    "delegate"
           Product: D
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: andrei metalanguage.com


Consider:

void foo(alias pred)() {
    pragma(msg, pred.stringof);
}

unittest {
    foo!((i) { return i < 0; })();
    int z = 1;
    foo!((i) { return i < z; })();
}

void main(string[] args)
{
}

This outputs:

__funcliteral1(__T2)
__dgliteral3(__T4)

because the first literal does not have to be a delegate.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 08 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3235






07:17:17 PDT ---


 Consider:
 
 void foo(alias pred)() {
     pragma(msg, pred.stringof);
 }
 
 unittest {
     foo!((i) { return i < 0; })();
     int z = 1;
     foo!((i) { return i < z; })();
 }
 
 void main(string[] args)
 {
 }
 
 This outputs:
 
 __funcliteral1(__T2)
 __dgliteral3(__T4)
 
 because the first literal does not have to be a delegate.


I meant that right now this outputs:

__dgliteral1(__T2)
__dgliteral3(__T4)

and it should output:

__funcliteral1(__T2)
__dgliteral3(__T4)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 08 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3235


Stewart Gordon <smjg iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |smjg iname.com
         Resolution|                            |INVALID





This is as designed.

http://www.digitalmars.com/d/1.0/expression.html#FunctionLiteral
"If the keywords function or delegate are omitted, it defaults to being a
delegate."

Having the type of a function/delegate literal depend on its contents like this
makes it hard for someone reading the code to tell which it is.  Since function
pointers and delegates are not generally interchangeable, AISI it's desirable
to keep their literal notations distinct.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 08 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3235






11:55:19 PDT ---


 This is as designed.
 
 http://www.digitalmars.com/d/1.0/expression.html#FunctionLiteral
 "If the keywords function or delegate are omitted, it defaults to being a
 delegate."
 
 Having the type of a function/delegate literal depend on its contents like this
 makes it hard for someone reading the code to tell which it is.  Since function
 pointers and delegates are not generally interchangeable, AISI it's desirable
 to keep their literal notations distinct.


I think type deduction should help here as much as anywhere else. If you do
want a delegate, you can always use the delegate keyword. Plus, all algorithms
in std.algorithm take an efficiency toll when used with literals.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 08 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3235


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |





11:57:05 PDT ---


 This is as designed.
 
 http://www.digitalmars.com/d/1.0/expression.html#FunctionLiteral
 "If the keywords function or delegate are omitted, it defaults to being a
 delegate."
 
 Having the type of a function/delegate literal depend on its contents like this
 makes it hard for someone reading the code to tell which it is.  Since function
 pointers and delegates are not generally interchangeable, AISI it's desirable
 to keep their literal notations distinct.


I think type deduction should help here as much as anywhere else. If you do
want a delegate, you can always use the delegate keyword. Plus, all algorithms
in std.algorithm take an efficiency toll when used with literals. 

(Please do not mark this as resolved; I've discussed with Walter before posting
it, and he suggested I do. In general, the spec of D2 is fluid enough to not be
a strong reason for invalidating a bug report. Thanks.)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 08 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3235




13:39:40 PDT ---
BTW this is in TDPL now, with Walter's approval.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 28 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3235


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|TDPL: Function literals     |[tdpl] Function literals
                   |must be deduced as          |must be deduced as
                   |"function" or "delegate"    |"function" or "delegate"



20:05:41 PST ---
The following example is in TDPL:

unittest
{
  auto f = (int i) {};
  assert(is(f == function));
}

The example fails to compile (it should). Also the following example should
work:

unittest
{
  int a;
  auto f = (int i) { a = i; };
  assert(is(f == delegate));
}

The compiler should automatically infer function or delegate type depending on
the literal's use of local state. The argument against it - people change a
detail in the body of the function and its type changes - is non sequitur.
Changing a literal from 10 to 10.0 also changes its type. Please fix.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 18 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3235


Kenji Hara <k.hara.pg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch



https://github.com/D-Programming-Language/dmd/pull/588

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 30 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3235


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |bugzilla digitalmars.com
         Resolution|                            |FIXED



12:22:38 PST ---
https://github.com/D-Programming-Language/dmd/commit/c50eb5f5726a65efa1224ff0f0fd60acbb6e3027

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 31 2011