• bearophile (42/42) Mar 04 2013 I am thinking about one enhancement request, but I am not sure if
• David (2/59) Mar 05 2013 http://dlang.org/phobos/std_functional.html#.toDelegate ?
• Jakob Ovrum (10/12) Mar 05 2013 The problem here is that the D calling convention for functions
• bearophile (4/7) Mar 05 2013 OK.

"bearophile" <bearophileHUGS lycos.com> writes:

I am thinking about one enhancement request, but I am not sure if 
the idea is meaningful, so I show it here first.

The presence of both function pointers and delegates makes the 
usage of higher order functions harder in D compared to function 
languages.

So maybe it's possible to support this code in D:

int foo(int x) { return x; }
void bar(int delegate(int) dg) {}
void main() {
     bar(&foo);
}


DMD 2.063alpha gives:

temp.d(4): Error: function temp.bar (int delegate(int) dg) is not 
callable using argument types (int function(int x))
temp.d(4): Error: cannot implicitly convert expression (& foo) of 
type int function(int x) to int delegate(int)



If you don't like implicit casts, then a possible alternative 
syntax:

int foo(int x) { return x; }
void bar(int delegate(int) dg) {}
void main() {
     bar(cast(delegate)&foo);
}

- - - - - - - - - -

An usage example where the difference between function pointers 
and delegates makes things much harder than necessary:


import std.stdio, std.algorithm;
T delegate(S) compose(T, U, S)(immutable T delegate(U) f,
                                immutable U delegate(S) g) {
     return s => f(g(s));
}
void main() {
     int delegate(int)[] functions = [x => x * 3,
                                      x => x * x,
                                      x => x + 2];
     auto allFunctions = functions.reduce!compose;
     allFunctions(5).writeln;
}


This works, but if you try to change that code a little, the 
compilation will fail in a surprisingly large variety of cases.

Bye,
bearophile

David <d dav1d.de> writes:

Am 05.03.2013 03:36, schrieb bearophile:
 I am thinking about one enhancement request, but I am not sure if the
 idea is meaningful, so I show it here first.
 
 The presence of both function pointers and delegates makes the usage of
 higher order functions harder in D compared to function languages.
 
 So maybe it's possible to support this code in D:
 
 int foo(int x) { return x; }
 void bar(int delegate(int) dg) {}
 void main() {
     bar(&foo);
 }
 
 
 DMD 2.063alpha gives:
 
 temp.d(4): Error: function temp.bar (int delegate(int) dg) is not
 callable using argument types (int function(int x))
 temp.d(4): Error: cannot implicitly convert expression (& foo) of type
 int function(int x) to int delegate(int)
 
 
 
 If you don't like implicit casts, then a possible alternative syntax:
 
 int foo(int x) { return x; }
 void bar(int delegate(int) dg) {}
 void main() {
     bar(cast(delegate)&foo);
 }
 
 - - - - - - - - - -
 
 An usage example where the difference between function pointers and
 delegates makes things much harder than necessary:
 
 
 import std.stdio, std.algorithm;
 T delegate(S) compose(T, U, S)(immutable T delegate(U) f,
                                immutable U delegate(S) g) {
     return s => f(g(s));
 }
 void main() {
     int delegate(int)[] functions = [x => x * 3,
                                      x => x * x,
                                      x => x + 2];
     auto allFunctions = functions.reduce!compose;
     allFunctions(5).writeln;
 }
 
 
 This works, but if you try to change that code a little, the compilation
 will fail in a surprisingly large variety of cases.
 
 Bye,
 bearophile

"Jakob Ovrum" <jakobovrum gmail.com> writes:

On Tuesday, 5 March 2013 at 02:36:45 UTC, bearophile wrote:
 I am thinking about one enhancement request, but I am not sure 
 if the idea is meaningful, so I show it here first.

The problem here is that the D calling convention for functions 
is different from that of delegates for whatever reason, hence an 
implicit cast would hide actual work (essentially the work 
toDelegate does).

As for an explicit cast, I don't see much value in it over 
toDelegate (as long as we can make toDelegate work for all cases 
- which is a test of perfect forwarding).

Anyway, I think there has been an enhancement request for this 
previously?

"bearophile" <bearophileHUGS lycos.com> writes:

Jakob Ovrum:

 As for an explicit cast, I don't see much value in it over 
 toDelegate (as long as we can make toDelegate work for all 
 cases - which is a test of perfect forwarding).

OK.

Bye,
bearophile