Add funcof operator to convert a single-method method group to a Func/Action

[ymassad]

Example:

class Program
{
    static void Main(string[] args)
    {
        var func = funcof(M);
    }

    static int M(string p) => p.Length;
}

The line that uses the funcof operator would be translated to something like:

var func = (Func<string, int>)M;

If the following is implemented:
#269

Then the type of the func variable would also contain the parameter names correctly.

The main benefit of such proposal is to be able to treat methods in C# as functions that can then be manipulated (e.g. partially invoked) and passed to other methods. This will make functional programming in C# easier.

Generic Methods

Supporting this proposal for non-generic method should be relatively easy.

I think it would be great to have support also for generic methods. As far as I know, C# currently does not allow a variable type to be an open generic.

For example, given this:

static int M<T>(T p1, string p2) => 1;

funcof(M) will be of type Func<T, string, int>. C# currently does not support a variable to be of this type (open).

If this is possible then we can do something like:

var func = funcof(M).PartiallyInvoke("value for string");

Where PartiallyInvoke is a generic user defined method that has many overloads to support partially invoking functions of different number of parameters and different indexes of the parameter to be fixed.

func in this case is of type Func<T,int>. I can invoke it now like this:

func(1) (T is now int)

or

func(1u) (T is now uint)

In the example, the PartiallyInvoke method overload is defined like this:

public static Func<TInput1, TOutput> PartiallyInvoke<TInput1, TInput2, TOutput>(
    this Func<TInput1, TInput2, TOutput> func,
    TInput2 input2)
{
    return input1 => func(input1, input2);
}

[HaloFour]

var func = funcof(M).PartiallyInvoke("value for string");

What do you propose that the type of func be here? I certainly can't be of Func<T, string int> because the generic type parameter would still be open.

Where PartiallyInvoke is a generic user defined method that has many overloads to support partially invoking functions of different number of parameters and different indexes of the parameter to be fixed.

Which immediately falls apart when a function has more than one parameter of the same type, e.g. Func<int, int, int>. Partial application and overloading don't mix.

[ymassad]

@HaloFour ,

What do you propose that the type of func be here?

It is Func<T, string, int>

I know that C# does not allow the generic type parameter to be open. I am suggesting to add support for this to C# (the CLR also?)

Which immediately falls apart when a function has more than one parameter of the same type

Because the function is of type Func<T, string, int> and we are passing a string, the compiler would detect that we need the overload I specified in the first post (updated after I wrote the post).

Maybe this feature should be implemented for non-generic methods first and then for generic methods later.

[ymassad]

@HaloFour , regarding updating C# to allow the generic type parameter to be open:

To make things easier, maybe we can have this support only for delegates (variables/expressions whose types are delegates), or maybe even the Func and Action delegates in specific.

[HaloFour]

@ymassad

The CLR doesn't support open generic type parameters like that. The bar for modifying the CLR is ridiculously high.

Because the function is of type Func<T, string, int> and we are passing a string.

But if the function is of type Func<T, int, int> and you pass an int it would be impossible to know which argument you are attempting to call. Not to mention it's impossible to know if you're ever attempting to partially apply the first argument since literally any call to PartiallyInvoke would apply.

You can do some degree of currying and partial application with extension methods today.

[ymassad]

But if the function is of type Func<T, int, int> and you pass an int it would be impossible to know which argument you are attempting to call

Do you mean Func<int, int, int> or maybe Func<T, int,int, int>?

Also, I am not sure I understand the following part:

Not to mention it's impossible to know if you're ever attempting to partially apply the first argument since literally any call to PartiallyInvoke would apply.

[ymassad]

If the CLR is hard to change, here is some idea that might work:

class Program
{
    static void Main(string[] args)
    {
        var func = funcof(M);
        //typeof(func) is AdvancedFuncDelegate_Param1IsOpen_Param2IsClosed_ReturnClosed<string, int>

        func(1, "str");
        //translates to func.Get<int>()(1, "str")

        func(2u, "str");
        //translates to func.Get<uint>()(2u, "str")

        var func_int = func<int>; //of type Func<int,string,int>
        //translates to var func_int = func.Get<int>()
    }

    public static int M<T>(T p1,string p2 ) => 1;
}

UPDATE: fixed the sample code above. I originally passed the wrong arguments to func

The following type is one of many types that should be part of the BCL:

public sealed class AdvancedFuncDelegate_Param1IsOpen_Param2IsClosed_ReturnClosed<TClosed2, TClosedOutput>
{
    private readonly MethodInfo method;
    private readonly object instance;//for non-static methods

    public AdvancedFuncDelegate_Param1IsOpen_Param2IsClosed_ReturnClosed(
        MethodInfo method,
        object instance)
    {
        this.method = method;
        this.instance = instance;
    }

    public Func<TOpen1, TClosed2, TClosedOutput> Get<TOpen1>()
    {
        //use method and instance to return a closed Func
        
    }
}

I am not sure how easy would it be though to write extension methods like PartiallyInvoke in this case.

[HaloFour]

@ymassad

Oops, I meant Func<T, int, int, int> or Func<int, int, int>, either way where you couldn't differentiate specific arguments by their type. Then you also have the entire problem of implicit conversion which could apply to multiple arguments, e.g. Func<T, short, long, string> and trying to use PartialInvoke(0).

Exactly what use cases are there for a feature like this? You claim that it will make functional programming easier, but what does it enable that you can't accomplish today?

[ymassad]

@HaloFour ,

Here is a simple use case:

class Program
{
    static void Main(string[] args)
    {
        Action inform =
            funcof(InformCustomers)
                .PartiallyInvoke(
                    funcof(SendEmail).PartiallyInvoke("smtp1.local.lab", 25));

        inform();
    }

    static void InformCustomers(Action<EmailAddress, Subject, Body> sendEmail)
    {
        //..
    }

    static void SendEmail(
        EmailAddress email,
        Subject subject,
        Body body,
        string smtpServerAddress,
        int port)
    {
        //..
    }
}

It enables dependency injection via partial invocation (without using classes).

[HaloFour]

@ymassad

Those kinds of scenarios are already pretty easily solved through lamdbas and capturing, with less typing.

Action inform = () => InformCustomers((address, subject, body) =>
    SendEmail(address, subject, body, "smtp1.local.lab", 25));

[HaloFour]

@ymassad

Also, with your syntax and its dependence on identifying arguments by their type, what would happen if any of the parameters email, subject or body were string? You'd lose the ability to "partially invoke" the method with the SMTP server address. Application through lambdas requires specifying the position of those arguments which eliminates any ambiguity.

[ymassad]

@HaloFour , this is only true because the InformCustomers method does not have other parameters. Also PartiallyInvoke is long, it could be shorter like ParInv.

Action<int,int,int> inform = (param1, param2, param3) =>
    InformCustomers(param1, param2, param3,
      (address, subject, body) =>
         SendEmail(address, subject, body, "smtp1.local.lab", 25));

Action<int,int,int> inform =
            funcof(InformCustomers)
                .ParInv(
                    funcof(SendEmail).ParInv("smtp1.local.lab", 25));

[ymassad]

@HaloFour , I agree with you that we would have to rely more on parameter types instead of position. Maybe in the future, there would be a way to partially invoke using parameter names.

This feature: #259 (comment)
Will make things really easy by doing something like:

using strict Subject = string;

[HaloFour]

@ymassad

this is only true because the InformCustomers method does not have other parameters.

Why does that matter? You can either have the other parameters become parameters to the inform delegate, or you can capture them:

List<Customer> customerList = ...;
Action inform = () => InformCustomers((address, subject, body) =>
    SendEmail(address, subject, body, "smtp1.local.lab", 25), customerList);

Action<List<Customer>> inform = customerList => InformCustomers((address, subject, body) =>
    SendEmail(address, subject, body, "smtp1.local.lab", 25), customerList);

Also PartiallyInvoke is long, it could be shorter like ParInv.

Which also makes it intentionally obtuse.

[ymassad]

@HaloFour ,

You added one parameter only. With three it is much longer.

Action<int,int,int> inform = (param1, param2, param3) =>
    InformCustomers(param1, param2, param3,
      (address, subject, body) =>
         SendEmail(address, subject, body, "smtp1.local.lab", 25));

[ymassad]

@HaloFour ,

Also, can I use var instead of Action<int,int,int> when using lambdas?

[HaloFour]

@ymassad

You added one parameter only. With three it is much longer.

I don't find that to be a problem.

Also, can I use 'var' instead of Action<int,int,int> when using lambdas?

Nope, for the same reason var can't work with funcof. You need that to evaluate to some kind of type, and delegates are nominal.

[ymassad]

@HaloFour ,

var can't work with funcof

It would. With non-generic methods, funcof(M) would be translated to (Func<int, string>)M (where M is string M(int param).

If it is generic, with CLR support I think we should be able to use var since it would be translated to (Func<T,string>)M where M is string M(T param).

Also, with my other suggestion, the type would be AdvancedFuncDelegate_Param1IsOpen_ReturnClosed<string>. See my post: #1943 (comment)

[HaloFour]

@ymassad

So funcof can't work on methods that don't return values? Or that have ref or out parameters? There are additional concerns where it comes to trying to default the type of a delegate based on signature since they're not considered equivalent according to the CLR.

funcof also couldn't work with overloads since there is no single delegate type to which it could be converted.

[ymassad]

So funcof can't work on methods that don't return values?

It works. It would return Action<..>

Or that have ref or out parameters?

Right. Func and Action don't support ref and out, right?

There are additional concerns where it comes to trying to default the type of a delegate based on signature since they're not considered equivalent according to the CLR.

I don't understand this part.

funcof also couldn't work with overloads since there is no single delegate type to which it could be converted.

Right. It would only work with single-method method groups.

[HaloFour]

@ymassad

Right. Func and Action don't support ref and out, right?

Those delegates don't, but other delegates can. There's nothing special about Func<...> or Action<...>, they just happened to be a family of types added to the BCL so that they didn't have to keep defining new delegates for the simpler cases. Today the C# has no special knowledge of those types and treats them the same as it would any delegate.

There are additional concerns where it comes to trying to default the type of a delegate based on signature since they're not considered equivalent according to the CLR.

I don't understand this part.

The problem is that each delegate type is a separate type regardless of it's signature. Func<string, bool> and Predicate<string> are incompatible types, according to the CLR, despite having identical signatures.

[ymassad]

@HaloFour ,

I am specifically proposing that funcof would return Func<..> or Action<..>, not any other type of delegate.

If M has a ref or out parameter, there would be a compilation error.

[pnstickne]

If the point is partial application and a currying-like ("like") experience, perhaps something like the following which should be possible purely as compiler transformations.

static string F1(int a, long b) {}

var f1 = partialof(F1); // -> Func<int, Func<long, string>> ~~ 'a int -> 'b long -> string

If there is an overload:

static string F2(int a) {}
static string F2(int a, long b) {}

var f2 = partialof<int,string>(F2); // choose first method

And partially application 'within the same expression' as partialof could be partially eliminated by the compiler.

var f1a = partialof(F1)(10); // -> Func<long, string>

Or even if required as an inline parameter:

// where F1 can be any method and the compiler generates a partial application wrapper.
// the compiler knows the type of F1 (see above to disambiguate overloads) and args1..N
var f1b = partialof(F1, 10);

// "normal" invocation of standard Func<long, string> in f1b.
var r1a = f1b(long.MaxValue); // -> string

Allowing a partialof to also take a Func/Action (not just method group) and resolve. Note that the partialof invisioned here is an operator over all method groups (and function/action objects, etc) and there is no Func<..>.PartialInvoke. So funcof(..).Partial(..) becomes partialof(.., ..) or partialof(partialof(..), ..) depending on needs.

// unless applying multiple values at once, where the synthetic can skip steps, it's probably not super useful
var f1c = partialof(F1); // -> Func<int, long, string>
var r1b = partialof(f1c, 10, long.MaxValue); // -> string (allow partialof to also resolve)

It could also unify over void methods/Actions.

static void F3(int a) {}

var f3 = partialof(F3); // -> Action<int>
var f3 = partialof<int, void>(F3); // explicit using (making up) 'void' as the return type specified in the overload

Useful or 'performant' or not in general? shrug. However it decomposes into a similar manner as some other languages..

The above can currently be handled in C#, albeit requiring the 'long handed' typing.

Restrictions:

• The usage of out/ref can is forbidden especially as they are "not common" in a more functional'ish programming style. This does not fit partial application well.
• Named parameters in the functions are not carried through. This does defeat the "Then the type of the func variable would also contain the parameter names correctly." in the original post. While sometimes convenient, as shown with ValueTuple and anonymous types, this feels a bit orthogonal to partial application anyway.

These restrictions mitigate many (all?) of the issues above around delegates, and using partialof(instance, ..) instead of having a Partial/PartiallyInvoke on the Func<..> type allows for the compiler to synthesize exactly was is needed.