auto fun = (para)=>{...};
auto  fun = (para){...};
auto fun = delegate(para){...};
auto fun = function(para){...};
--------------------------------------------
void on(void delegate(int)callback){...}

on((para)=>{...});
on((para){...});
on(delegate(para){...});
on(function(para){...});
--------------------------------------------
some of them has the attribute @safe nothrow or @system,others
don't .
Is that inconsistency a intended design or not ?
The additional attributes  make some function parameter passing
not work since they have different signature .

On 09/06/2012 06:32 AM, Anderel Cerol wrote:
> auto fun = (para)=>{...};

This is the same as auto fun = (para){ return (){ ... }; };

The syntax is:

(params)=>expression

{...} // a function literal with body ...

Therefore (params)=>{...}

is the composition of two function literals.

> auto  fun = (para){...};

The types of function literals depend on the actual function bodies
(and their usage).
If the function bodies refer to an outer dynamic context, they are
deduced as delegate types, otherwise they are function pointer types.

(A delegate is a fat pointer that includes a function pointer and a
frame pointer to support eg. lexical closure.)

> auto fun = delegate(para){...};
> auto fun = function(para){...};

These disable the deduction and force either delegate or function
(compile time error, if the body of the function pointer literal
attempts to access an outer dynamic scope.)

> --------------------------------------------
> void on(void delegate(int)callback){...}
>
> on((para)=>{...});

This won't work, because the delegate return type is the type of some
function literal instead of void.

> on((para){...});

Should work if the body does not return a value.

> on(delegate(para){...});

Same here.

> on(function(para){...});

function pointers are incompatible with delegates.
std.functional.toDelegate can be used to create a delegate from a
function pointer if needed.

> --------------------------------------------
> some of them has the attribute @safe nothrow or @system,others
> don't .
> Is that inconsistency a intended design or not ?

Function literals infer @safe nothrow or @system. As long as you do not
provide the actual function bodies I cannot answer this.

> The additional attributes
> make some function parameter passing
> not work since they have different signature .
>

This is not what is happening, as explained above.

On Thursday, 6 September 2012 at 04:51:28 UTC, Timon Gehr wrote:
> On 09/06/2012 06:32 AM, Anderel Cerol wrote:
>> auto fun = (para)=>{...};
>
> This is the same as auto fun = (para){ return (){ ... }; };
>
> The syntax is:
>
> (params)=>expression
>
> {...} // a function literal with body ...
>
> Therefore (params)=>{...}
>
> is the composition of two function literals.
>
>> auto  fun = (para){...};
>
> The types of function literals depend on the actual function bodies
> (and their usage).
> If the function bodies refer to an outer dynamic context, they are
> deduced as delegate types, otherwise they are function pointer types.
>
> (A delegate is a fat pointer that includes a function pointer and a
> frame pointer to support eg. lexical closure.)
>
>> auto fun = delegate(para){...};
>> auto fun = function(para){...};
>
> These disable the deduction and force either delegate or function
> (compile time error, if the body of the function pointer literal
> attempts to access an outer dynamic scope.)
>
>> --------------------------------------------
>> void on(void delegate(int)callback){...}
>>
>> on((para)=>{...});
>
> This won't work, because the delegate return type is the type of some
> function literal instead of void.
>
>> on((para){...});
>
> Should work if the body does not return a value.
>
>> on(delegate(para){...});
>
> Same here.
>
>> on(function(para){...});
>
> function pointers are incompatible with delegates.
> std.functional.toDelegate can be used to create a delegate from a
> function pointer if needed.
>
>> --------------------------------------------
>> some of them has the attribute @safe nothrow or @system,others
>> don't .
>> Is that inconsistency a intended design or not ?
>
> Function literals infer @safe nothrow or @system. As long as you do not
> provide the actual function bodies I cannot answer this.
>
>> The additional attributes
>> make some function parameter passing
>> not work since they have different signature .
>>
>
> This is not what is happening, as explained above.

a real example is :
....
import std.net.curl;
auto http=HTTP();
...
http.onReceiveStatusLine(...);
...

the function http.onReceiveStatusLine(...) is exactly what the function on(...) is above.
The environment is dmd 2.060 Windows.

>
> a real example is :
> ....
> import std.net.curl;
> auto http=HTTP();
> ...
> http.onReceiveStatusLine(...);
> ...
>
> the function http.onReceiveStatusLine(...) is exactly what the function on(...) is above.
> The environment is dmd 2.060 Windows.
plus, what passes to the http.onReceiveStatusLine is just (a){a.writeln();} with different forms above.

On Thursday, 6 September 2012 at 05:18:24 UTC, Anderel Cerol wrote:
>
>>
>> a real example is :
>> ....
>> import std.net.curl;
>> auto http=HTTP();
>> ...
>> http.onReceiveStatusLine(...);
>> ...
>>
>> the function http.onReceiveStatusLine(...) is exactly what the function on(...) is above.
>> The environment is dmd 2.060 Windows.
> plus, what passes to the http.onReceiveStatusLine is just (a){a.writeln();} with different forms above.

by the way ,std.functional.toDelegate doesn't work as UFCS style,why ?

On 09/05/2012 11:31 PM, Anderel Cerol wrote:
> On Thursday, 6 September 2012 at 05:18:24 UTC, Anderel Cerol wrote:
>>
>>>
>>> a real example is :
>>> ....
>>> import std.net.curl;
>>> auto http=HTTP();
>>> ...
>>> http.onReceiveStatusLine(...);
>>> ...
>>>
>>> the function http.onReceiveStatusLine(...) is exactly what the
>>> function on(...) is above.
>>> The environment is dmd 2.060 Windows.
>> plus, what passes to the http.onReceiveStatusLine is just
>> (a){a.writeln();} with different forms above.
>
> by the way ,std.functional.toDelegate doesn't work as UFCS style,why ?

Can you be more specific please: What "doesn't work"? The following code is slightly modified from toDelegate's documentation, demonstrating that it indeed does work with UFCS:

import std.stdio;
import std.functional;

void doStuff() {
    writeln("Hello, world.");
}

void runDelegate(void delegate() myDelegate) {
    myDelegate();
}

void main()
{
    // auto delegateToPass = toDelegate(&doStuff);
    auto delegateToPass = (&doStuff).toDelegate();
    runDelegate(delegateToPass);  // Calls doStuff, prints "Hello, world."
}

Ali

On Thursday, 6 September 2012 at 06:41:37 UTC, Ali Çehreli wrote:
> On 09/05/2012 11:31 PM, Anderel Cerol wrote:
> > On Thursday, 6 September 2012 at 05:18:24 UTC, Anderel Cerol
> wrote:
> >>
> >>>
> >>> a real example is :
> >>> ....
> >>> import std.net.curl;
> >>> auto http=HTTP();
> >>> ...
> >>> http.onReceiveStatusLine(...);
> >>> ...
> >>>
> >>> the function http.onReceiveStatusLine(...) is exactly what
> the
> >>> function on(...) is above.
> >>> The environment is dmd 2.060 Windows.
> >> plus, what passes to the http.onReceiveStatusLine is just
> >> (a){a.writeln();} with different forms above.
> >
> > by the way ,std.functional.toDelegate doesn't work as UFCS
> style,why ?
>
> Can you be more specific please: What "doesn't work"? The following code is slightly modified from toDelegate's documentation, demonstrating that it indeed does work with UFCS:
>
> import std.stdio;
> import std.functional;
>
> void doStuff() {
>     writeln("Hello, world.");
> }
>
> void runDelegate(void delegate() myDelegate) {
>     myDelegate();
> }
>
> void main()
> {
>     // auto delegateToPass = toDelegate(&doStuff);
>     auto delegateToPass = (&doStuff).toDelegate();
>     runDelegate(delegateToPass);  // Calls doStuff, prints "Hello, world."
> }
>
> Ali

I coded like this :
auto func ={
......
};
import std.functional;
func.toDelegate(); //doesn't work ,shows "undefined identifier toDelegate "
toDelegate(func); //works.

On Friday, 7 September 2012 at 05:56:18 UTC, Anderel Cerol wrote:
> I coded like this :
> auto func ={
> ......
> };
> import std.functional;
> func.toDelegate(); //doesn't work ,shows "undefined identifier toDelegate "
> toDelegate(func); //works.

Looks like scoped imports don't play nicely with UFCS. Put the
import in module scope and it works. Of course, that's just a
workaround, and you should report it as a bug.

On Friday, 7 September 2012 at 06:13:17 UTC, anonymous wrote:
> you should report it as a bug.

Already in there: http://d.puremagic.com/issues/show_bug.cgi?id=6185