(In reply to comment #0)

Here is a possible patch:

/**
Takes a D function, and curries it (in traditional, mathematical sense): given
a n-args function, it creates n 1-arg functions nested inside one another. When
all original arguments are reached, it returns the result.

Example:
----
int add(int i, int j) { return i+j;}
alias curry!add cadd; // cadd waits for an int, will return an int delegate(int)
auto add3 = cadd(3); // add3 is a function that take an int and return this int + 3.

auto m = map!add3([0,1,2,3]);
assert(equal(m, [3,4,5,6]));

bool equals(int i, int j) { return i==j;}
alias curry!equals cequals;
auto equals4 = cequals(4); // equals4 is a function taking an int and return true iff this int is 4.
auto f = filter!equals4([2,3,4,5,4,3,2,2,3,4]);
assert(equal(f, [4,4,4]));
----

What's fun is that it'll work for template functions too.

Example:
----
string conj(A, B)(A a, B b)
{
    return to!string(a)~to!string(b);
}

alias curry!conj cconj;
auto c1 = cconj(1); // c1 is a template function waiting for any type.
assert(c1('a') == "1a");
----
BUG:
for now, it does not verify the compatibility of types while you give it the arguments. It's only
at the end that it sees whether or not it can call the function with these arguments.
Example:
----
// given a function like this, with dependencies between the arguments' types:
A foo(A,B,C)(A a, Tuple!(B,A) b, Tuple!(C,B,A) c) { return a+b.field[1]+c.field[2];}
// if you curries it and gives it an int as first argument, the returned template function should really be:
int foo2(B,C)(Tuple!(B,int) b) { return anotherFunction;}
// because we now know A to be an int...
----
*/
template curry(alias fun)
{
    static if (isFunction!fun)
        enum curry =  mixin(curryImpl!(fun, "", ParameterTypeTuple!fun));
    else
        enum curry = curriedFunction!(fun)();
}

template curryImpl(alias fun, string xs, T...)
{
    static if (T.length == 0)
        enum curryImpl = "&fun";
    else static if (T.length == 1)
        enum curryImpl = "(" ~ T[0].stringof  ~ " x1) { return fun(" ~ xs ~ "x1);}";
    else
        enum curryImpl = "(" ~ T[0].stringof  ~ " x" ~ to!string(T.length) ~ ") { return "
                            ~ curryImpl!(fun,xs ~ "x" ~ to!string(T.length) ~ ", ", T[1..$]) ~ ";}";
}

struct CurriedFunction(alias fun, T...) /+if (T.length)+/
{
    T _t;
    static if (T.length)
        void initialize(T t) { _t = t;}

    template OpCallType(U...)
    {
        static if (is (typeof(fun(Init!T, Init!U))))
            alias typeof(fun(Init!T, Init!U)) OpCallType;
        else
            alias CurriedFunction!(fun, T, U) OpCallType;
    }

    OpCallType!U opCall(U...)(U u)
    {
        static if(is(typeof(fun(_t, u))))
            return fun(_t,u);
        else
        {
            CurriedFunction!(fun, T, U) cf;
            static if (U.length) cf.initialize(_t, u);
            return cf;
        }
    }
}

CurriedFunction!(fun, TypeTuple!()) curriedFunction(alias fun)()
{
    CurriedFunction!(fun, TypeTuple!()) cf;
    return cf;
}

unittest
{
    int add(int i, int j) { return i+j;}
    alias curry!add cadd; // cadd waits for an int, will return an int delegate(int)
    auto add3 = cadd(3); // add3 is a function that take an int and return this int + 3.

    auto m = map!add3([0,1,2,3]);
    assert(equal(m, [3,4,5,6]));

    bool equals(int i, int j) { return i==j;}
    alias curry!equals cequals;
    auto equals4 = cequals(4); // equals4 is a function taking an int and return true iff this int is 4.
    auto f = filter!equals4([2,3,4,5,4,3,2,2,3,4]);
    assert(equal(f, [4,4,4]));
}
 

So, the template function part is still a bit rough. I've plan to keep track of types dependencies, but ... well, Real Life (tm) is in the way.

I suggest to also keep the current implementation of "curry", but to rename it to "partial".

@Timon: Agreed, having a »curry« that really performs partial application is quite confusing (and gets us into trouble if we want to add a real curry), this has been on my todo list for quite some time now.

Commit pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/35c743967bf033b4600afe5385e52915693f299b
Merge pull request #1979 from msoucy/issue4391a

Renamed curry->partial to better match semantics

There has been some discussion about this in the NG:

http://forum.dlang.org/post/vehmitraloqhwtxnjqzr@forum.dlang.org

but unfortunately AFAICT curry still hasn't made its way into Phobos.
What happened to the patch Philippe posted?

@Andrei: The status says that this is assigned to you. I will set the status to "unassigned", please change you have this on your roadmap.

Put this up for bootcamp.

@benjones updated dlang/phobos pull request #6963 "bugzilla issue 4391 add curry to std.functional " fixing this issue:

- Fix Issue 4391 - add curry to std.functional

https://github.com/dlang/phobos/pull/6963

dlang/phobos pull request #6963 "bugzilla issue 4391 add curry to std.functional " was merged into master:

- 866c0779d1d67c7863abea8974355d3e5eac0650 by Ben Jones:
  Fix Issue 4391 - add curry to std.functional

https://github.com/dlang/phobos/pull/6963