Proposal: Currying support for non Generic, non params, non default functions.

[SteffenBlake]

Simply put, plain ole functions that dont have optionals, defaults, params, out vars, async, etc on them, should have baked in support for currying. This is a wonderful F# feature I adore and would love to see come to C# as well.

This can already be achieved via lambdas, so the goal would be to simply add support for this with some syntactical sugar to cut down on effort. Especially useful for unit testing where we may have numerous params in a function but we are only changing one of them for each assertion.

public void PrintNumbers(int a, int b, int c, int d) {
    Console.Writeline($"{a}, {b}, {c}, {d}");
}

public int SumNumbers(int a, int b) => a+b;

// Currying of an Action / Void Method
Action<int> curriedPrintNumbers = PrintNumbers(1, 2, 3); // Note we didnt use the fourth variable (yet)

curriedPrintNumbers(4);
curriedPrintNumbers(5);
curriedPrintNumbers(6);

Func<int> curriedSumNumbers = SumNumbers(3);

var foo = curriedSumNumbers(4);
var bar = curriedSumNumbers(8);

Console.WriteLine(foo);
Console.WriteLine(bar);

Output:

1, 2, 3, 4
1, 2, 3, 5
1, 2, 3, 6
7
11

This is extremely useful for unit testing, where perhaps I may have a service with a method like:

class UserStore {
    public void UpdateUser(DbContext context, TransactionState state, IContext context, IUser executingUser, IUser user);
}

And I have a unit test that composes numerous users and calls this method on each of them, my code goes from this:

var userA = CreateUser(...User A contextual Params...);
var userB = CreateUser(...User B contextual Params...);
var userC = CreateUser(...User C contextual Params...);
var userD = CreateUser(...User D contextual Params...);
var userE = CreateUser(...User E contextual Params...);

Assert.DoesntThrow(myUserStore.UpdateUser(dbContext, state, context, executingUser, userA));
Assert.DoesntThrow(myUserStore.UpdateUser(dbContext, state, context, executingUser, userB));
Assert.DoesntThrow(myUserStore.UpdateUser(dbContext, state, context, executingUser, userC));
Assert.DoesntThrow(myUserStore.UpdateUser(dbContext, state, context, executingUser, userD));
Assert.DoesntThrow(myUserStore.UpdateUser(dbContext, state, context, executingUser, userE));

Instead, I could do for those 5 lines:

var myUpdateUser = myUserStore.UpdateUser(dbContext, state, context, executingUser);

Assert.DoesntThrow(myUpdateUser(userA));
Assert.DoesntThrow(myUpdateUser(userB));
Assert.DoesntThrow(myUpdateUser(userC));
Assert.DoesntThrow(myUpdateUser(userD));
Assert.DoesntThrow(myUpdateUser(userE));

Substantially cleaner! I could see some of the more complicated, non plain functions also supporting this. Specifically, async functions probably could work with this. CancellationTokens get along extremely well with currying.

Currently, this is also totally supported in C# anyways, and it purely is syntactical sugar as a shorthand for:

Func<int> curriedSumNumbers = (b) =>  SumNumbers(3, b);

Which would now just become:

var curriedSumNumbers  = SumNumbers(3);

So smooth!

[TonyValenti]

I'd rather see:

''''
var curry = (x) => foo(1,2,3,x);
''''

[Unknown6656]

I do absolutely love currying, however, I am not totally comfortable with the proposed syntax.

List of partially/mildly related issues:
#96
#74
#2604

[FrancisHogle]

I recently posted #9552 regarding partial application and was referred here. Also partially/mildly related :)

It seems like community energy behind currying and partial application should be grouped together.

[DavidArno]

I'm unclear what advantage,

Action<int> curriedPrintNumbers = PrintNumbers(1, 2, 3);

brings over the currently supported syntax:

Action<int> curriedPrintNumbers = x => Numbers(1, 2, 3, x);

that would justify the work required to add this to the language. I'm definitely with @TonyValenti here in that I'd far prefer to be able to express it as:

var curriedPrintNumbers = x => Numbers(1, 2, 3, x);

and have it infer Action/Func as appropriate.

[SteffenBlake]

@DavidArno that proposed syntax brings up a lot of covarient/contravarient issues.

The proposed syntax is:

var curriedPrintNumbers = PrintNumbers(1, 2, 3);

[HaloFour]

The variance issues would exist either way as the result of currying would have to be a delegate.

For example, the following would not be legal:

var f1 = SumNumbers(2);
Func<object, object> f2 = sumNumbers; 

I'm also with everyone else that if the language were to gain currying that it should do so through an explicit syntax. I'd be cool with something like:

var curried = SumNumbers(2, ...);

Although that isn't much less verbose than using lambdas today.

With overloading and optional parameters it's already quite confusing to the developer to try to figure out exactly what method a given call might try to make, and overload resolution is already one of the most complicated aspects of the C# compiler. If all of a sudden the omission of an argument would result in a successful compilation but return some arbitrary delegate type I think a lot of potential bugs would be missed only to result in weird runtime errors.

[SteffenBlake]

@HaloFour a multitude of e isting languages, including F#, use currying, and this should not result in runtime but compile time errors.

Attempting to use a Func<int, int> as an int would instantly arise compile time mismatch type errors that instantly highlight your problem.

The variance issue I referred to is not in the casting of a Func<int, int> to a Func<object, object>, but in the act of wanting the compiler to infer lamba paramaters off their usage.

Which violates their variance.

Because the compiler can't tell the difference between:

var foo = (x) => PrintNumbers(1, 2, 3, x);

And

var foo = (x) => PrintNumbers(1, 2, 3, 4);

In the second case, x is...? Attempting to infer the lambda parameters off how they get used violates a lot of stuff.

However note that:

var curriedPrintNumbers = PrintNumbers(1, 2, 3);

Have done away with that x which actually simplifies away that variance problem.

I would also be fine with a notation that specifies an intentional curry, to prevent accidental currying (and make intellisense have an easier time)

Perhaps the _ symbol to represent variables we wish to curry?

That could open up the option of even doing:

var curriedPrintNumbers = PrintNumbers(1, _, 3, _);

Which would produce an Action<int, int>

[HaloFour]

@SteffenBlake

a multitude of e isting languages, including F#, use currying

Many of those languages, like F#, forbid currying and overloading from being used at the same time. You can curry functions, but not overload them or specify optional parameters. IIRC, you can overload methods, but not curry them.

and this should not result in runtime but compile time errors.

Depends on what the program does with the result. Yes, if the program tries to treat the result as the return value of the method then it should result in a compiler error. But if the program boxes the type or passes it to a method overloaded by a delegate type the compiler would not catch the problem. Either way the compiler can't check that the invocation has the correct number of arguments.

Which violates their variance.

Oh, you mean inference? Yes, target type inference would probably be a lot more complicated in those scenarios. You can explicitly specify the type of the argument in the lambda, or explicitly specify the type of the target delegate.

[TonyValenti]

I think I'd be very happy with:

var foo = (x) => PrintNumbers(1, 2, 3, 4);

being disambiguated by:

var foo = (int x) => PrintNumbers(1, 2, 3, 4);

I just hate having to type Action<...> and Func<...> in code. I feel like there should be automatic conversion/equivalency between Actions/Funcs and any kind of delegate with a matching or compatible signature.

[SteffenBlake]

With regard to:

var foo = (int x) => PrintNumbers(1, 2, 3, 4);

Note that (int x) could be mistaken for a Tuple, no?

[canton7]

Note that (int x) could be mistaken for a Tuple, no?

1. Tuples must contain at least two elements
2. Action<int> foo = (int x) => Console.WriteLine(x); is already valid