Thread overview
To lessen the function pointers/delegates distinction
Mar 05, 2013
bearophile
Mar 05, 2013
David
Mar 05, 2013
Jakob Ovrum
Mar 05, 2013
bearophile
March 05, 2013
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
March 05, 2013
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 ?
March 05, 2013
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?
March 05, 2013
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