The first fragment will only make sense if it is accompanied by several similar overloads. Probably just to complete a set of methods called Curry . This word comes from the name Haskell Curry and refers to the ability in a programming language (or library) to provide a subset of the required parameters for a function to get another function that takes the rest of the functions. This is easier to understand with an example:
void Foo(int a, string b, bool c) { ... }
You can call this by specifying all three parameters:
Foo(123, "hi", false);
But in currying you can do this:
var foo123 = Foo(123);
It returns another function that takes the remaining two parameters, so we say that it βbindsβ the first parameter to 123. But if you can curry with the original function, you can curry with the new one:
var foo123Hi = foo123("hi");
And finally, put the last argument:
foo123Hi(false);
Finally, we have all three arguments, and only now our definition of Foo for real is really satisfied.
In many functional languages ββ(not surprisingly in Haskell and Curry), this is built into the language. This is not the case in C #, although you can partially imitate it by providing a set of overloads such as:
Action<string, bool> Foo(int a) { return (b, c) => Foo(a, b, c); } Action<bool> Foo(int a, string b) { return c => Foo(a, b, c); }
But this is still not entirely correct, because in the first example, the returned Action<string, bool> will not work directly with curry.
Thus, sometimes attempts are made to provide a currying library that will allow currying of any function.
But with a fairly simple lambda syntax, itβs actually not clear that any library solution would be useful. After all, lambda is a very simple way to bind a single parameter, as shown in the examples above. Therefore, I am not sure how widely used the Curry method library. The operator => is clearer, less awkward, more powerful and readable and already built-in.