www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - To lessen the function pointers/delegates distinction

reply "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
Mar 04 2013
next sibling parent 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
http://dlang.org/phobos/std_functional.html#.toDelegate ?
Mar 05 2013
prev sibling parent reply "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?
Mar 05 2013
parent "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
Mar 05 2013