Support native partial application for methods and delegates

[leandromoh]

When digging into functional programming we usually goes through partial application (of methods), and since C# is getting more functional each time, would be nice have a suggar for it become more usual.

Partial application is the process of pass part of the arguments of a method, returning new a method that receives the rest of the arguments. For example, If you provide 1 out of 3 arguments, it'll return a function that takes 2 arguments. If you provide 2 out of 3 arguments, it'll return a method that takes 1 argument.

The general benefit that this approach gives you is that it’s a way to create specialized methods from more general methods. It is a simple technique, but very powerfull.

The idea of this proposal is allow it for methods (with return value or not) and delegates (like Func, Action, etc) through syntax suggar of the current approach, that is to wrap the original call by writting an anonymous function.

There are possible complications in cases bellow, so this feature would not be avaible for them in this proposal:

• methods with overloads
• methods with optional parameters
• methods with in, ref, out modifiers

Consider method

public int Add(int num1, int num2, int num3) => num1 + num2 + num3;

Current approach:

Func<int, int, int> add4 = (num2, num3) => Add(4, num2, num3);
Func<int, int> add5 = num3 => Add(2, 3, num3);

Could be simplified having the suggar:

Func<int, int, int> add4 = Add(4);
Func<int, int> add5 = Add(2, 3);

We could also use named arguments to specify non sequential parameters

Current approach:

Func<int, int> add4 = num2 => Add(3, num2, 1);

Could be simplified having the suggar:

Func<int, int> add4 = Add(num1: 3, num3: 1);

Something that could simplify even more these declarations is that, since partial application would be avaible only for methods/delegates and not for linq's expressions, partial application could be inferred as Func or Action when not specified. So the above examples

Func<int, int> add5 = Add(2, 3);
Func<int, int> add4 = Add(num1: 3, num3: 1);

Could be simplified even more to

var add5 = Add(2, 3);
var add4 = Add(num1: 3, num3: 1);

[HaloFour]

IMO the explicit syntax is much clearer about what's going on. There's nothing about Add(4) that tells me that this is some kind of partial application resulting in the allocation of some arbitrary type of delegate. Having the compiler try to do that automatically based on incomplete method invocations would complicate method overload resolution considerably.

[Richiban]

would complicate method overload resolution considerably

It's also worth noting that even F# doesn't support partial application on .NET methods--only on F# functions--almost certainly because of the impossibility of overload resolution.

[leandromoh]

Having the compiler try to do that automatically based on incomplete method invocations would complicate method overload resolution considerably.

Even if the methods doest not have overloads (one single method definition), would compiler have a complicated overload resolution?

It's also worth noting that even F# doesn't support partial application on .NET methods--only on F# functions--almost certainly because of the impossibility of overload resolution.

Yeah! The ideia is the same here, but since C# does support method overload, it would be avaible only for methods with no overloading

[HaloFour]

@leandromoh

Even if the methods doest not have overloads (one single method definition), would compiler have a complicated overload resolution?

Yes. Even if it's simple for the compiler to figure out what you mean it's still a lot for the developer to have to understand and interpret when reading code for every single method invocation that they encounter. They already have to consider type coercion, optional parameters, params and extension methods. Adding another flavor with very different semantics only makes that much more complicated. It also means that a whole category of mistakes that would have previously been caught by the compiler would now successfully compile.

IMO partial application and currying just shouldn't mix with overloading. The few languages that have both have a very clear delineation as to where each can be used. You could make the argument that this could apply to C# local functions since they forbid overloading and shadow any members but I doubt they'd be worth the complexity.

[YairHalberstadt]

Even if the methods doest not have overloads (one single method definition), would compiler have a complicated overload resolution?

That would make adding another overload almost always a breaking change since somebody is likely to have used it for partial application. Whilst it already can cause breaking changes they tend to be less frequent.

[kharai-tor]

Doesn't work when method arguments have default values either:

int PerformCalculation(int x, int y = 0) 
{
    // something...
}

Then:

var result = PerformCalculation(100);

Would this be a partially applied call? Or a regular method call?

I'm a fan of FP too. But some ideas just don't fit in C#.

[FiniteReality]

Would using discards as placeholders work? e.g.

var add5 = Add(2, 3, _);

This way you're explicitly specifying that you're only partially applying some parameters, and are explicitly ignoring the rest. It could probably be implemented similarly to var, except that instead of only being valid when there's no type in scope named var, it'd be valid only when there's no variable named _ in scope.

I've personally been interested in using partial application myself, to hide implementation details where appropriate, and while I'm not sure a dedicated syntax is super necessary for my use cases, it would be a lot more convenient to write

[leandromoh]

I gonna close this discussion.
@FiniteReality @TKharaishvili I created the Curryfy lib/nuget that does it whilst C# does provide a feature for it. Hope it might help you.