Proposal: Functors

[iam3yal]

Summary

Generialize delegate invocation for user-defined classes/structs.

Motivation

Generalization of delegate invocation in order to support the following use-cases:

1. Support state where delegates and methods cannot be used.

2. Support hierarchies where delegates and methods cannot be used.

This can be thought as a more "primitive" type of delegates to some extent.

Detailed design

A class that implements the Invoke method will allow instances to be invoked using the same syntax used for delegate invocation.

Example:

public abstract class BinaryOperation<T>
{
	public virtual T Invoke(T a, T b)
	{
		var param_a = Expression.Parameter(typeof(T), "a");
		var param_b = Expression.Parameter(typeof(T), "b");

		var expr_body = Create_Operation(param_a, param_b);

		var func_add = Expression.Lambda<Func<T, T, T>>(expr_body, param_a, param_b).Compile();

		return func_add(a, b);
	}

	protected abstract BinaryExpression Create_Operation(ParameterExpression a, ParameterExpression b);
}

public class Add<T> : BinaryOperation<T>
{
	protected override BinaryExpression Create_Operation(ParameterExpression a, ParameterExpression b) => Expression.Add(a, b);
}

public class Multiply<T> : BinaryOperation<T>
{
	protected override BinaryExpression Create_Operation(ParameterExpression a, ParameterExpression b) => Expression.Multiply(a, b);
}

Today, we must explicitly call the method Invoke like so:

var a = new Add<int>();
var m = new Multiply<int>();
	
Console.WriteLine(m.Invoke(a.Invoke(2, 3), a.Invoke(2, 3)));
Console.WriteLine(a.Invoke(m.Invoke(2, 3), m.Invoke(2, 3)));

With this proposal we could reduce the noise quite a bit.

var a = new Add<int>();
var m = new Multiply<int>();
	
Console.WriteLine(m(a(2, 3), a(2, 3)));
Console.WriteLine(a(m(2, 3), m(2, 3)));

// Or

Console.WriteLine(a(2, 3) * a(2, 3));
Console.WriteLine(m(2, 3) + m(2, 3));

Please let's not go into what the names of the class should be as in verbs vs nouns or whatever because this is really debatable.

Drawbacks

@JeffreySax made a comment about one possible drawback in the previous proposal so I'll just cite him:

namespace N1
{
    public static class X
    {
        public static void F(int x) { }
    }
}
namespace N2
{
    using static N1.X;
    class A
    {
        public void Invoke(int x) { }
    }
    class B
    {
        public A F { get; }
        void M()
        {
            F(1);
        }
    }
}

Right now, the call to F in B.M is resolved to N1.X.F. If A becomes callable because it happens to have an Invoke method, then the same call can also be resolved to A.Invoke on the F property.

Alternatives

1. As pointed out above, we can always define whatever method to execute the operation like this:

   var a = new Add<int>();
   var m = new Multiply<int>();
   	
   Console.WriteLine(m.Invoke(a.Invoke(2, 3), a.Invoke(2, 3)));
   Console.WriteLine(a.Invoke(m.Invoke(2, 3), m.Invoke(2, 3)));
   

   There's no real drawbacks here besides the needless verbosity and the fact that it looks awkward.

2. In the previous proposal @vbcodec suggested to use indexers like this:

   var a = new Add<int>();
   var m = new Multiply<int>();
   
   Console.WriteLine(m[a[2, 3], a[2, 3]]);
   Console.WriteLine(a[m[2, 3], m[2, 3]]);
   

   Known limitations of indexers:

   • They cannot have void as their return type.

   • They cannot be parameterless.

   Another thing about indexers that can be an annoyance and even lead to confusion is that they really feel out of place both syntactically and semantically, i.e, indexers are properties and as such the syntax are inherited from properties and finally the semantics are such that people associate them with accessing or mutating collections.

Prototype

Prototype available by @orthoxerox

[YaakovDavis]

There's another potential use case for this. If functors are supported, I propose also allowing to "derive" from delegate types. e.g.:

public class ParityComparison : System.Comparison<int>
{
    public int Invoke(int a, int b) => a % 2 == b % 2;
}

void foo()
{
   var rand  = new Random();
   var list = Enumerable.Range(0, 100).Select(i => rand.Next()).ToList();
   list.Sort(new ParityComparison());
}

This will allow explicit closing on state where it's needed.

[gafter]

What is wrong with just using indexers and [] at the call site?

[jnm2]

@gafter My first thought too, but won't work for void return.

The ability to derive a class from a delegate is the first thing that has interested me about this proposal.

[bbarry]

@gafter I don't mind having to explicitly call .Invoke() for usages of this pattern, but indexers seem quite wrong.

[iam3yal]

@gafter Besides the point that indexers must return a value there's also semantics people tend to think about indexers as "accessors" or "mutators" of collections and so they are more related to properties and they are in fact kind of properties so abusing indexers to mean a method call is a bit odd and can lead to confusion.

It's like abusing operators to mean something else, a citation from the guidelines about operators overloading:

Use operator overloading in cases where it is immediately obvious what the result of the operation will be. For example, it makes sense to be able to subtract one Time value from another Time value and get a TimeSpan. However, it is not appropriate to use the or operator to create the union of two database queries, or to use shift to write to a stream.

Also, the Indexers guideline suggests the following:

Avoid indexed properties with more than one parameter.

Functors may not have parameters at all or may have more than a single parameter.

Avoid indexers with parameter types other than System.Int32, System.Int64, System.String, System.Object, enumerations, or generic type parameters.

Functors may have parameters as user-defined types.

Updated this post and the OP with more details.

[iam3yal]

@bbarry Calling an .Invoke(...) method or .Calculate(...) method or whatever is what we're doing today the thing is that it's not as succinct and legible as it can be, I mean, think about C# without indexers or/and without properties, we can certainly workaround it, for example, C++ and Java do without it but many people wonder why they don't have these features.

[pharring]

C++ has operator () which may be a better 'spelling' of Invoke.

[iam3yal]

@pharring The idea originated there. :)

[svick]

@YaakovDavis

There's another potential use case for this. If functors are supported, I propose also allowing to "derive" from delegate types.

Would the type actually inherit from the delegate type? In other words, for your example, what would typeof(ParityComparison).IsSubclassOf(typeof(Comparison<int>)) return?

If the type was to actually inherit from the delegate type, that would require changes to the base library (since delegate types are currently sealed) and probably also to the CLR. If they did not actually inherit, I think that would be confusing.

[iam3yal]

@svick Well, I guess that this is why he said "potential use-case for this" but we aren't really discussing implementation details atm so the changes it will require can be discussed after we nail the use-cases for this. :)

[YaakovDavis]

@svick @eyalsk

Would the type actually inherit from the delegate type?

Would be nice it it could, but I wouldn't want the feature to be held back by BCL (& CLR) changes.

The inheritance difference is new, but it'll only become apparent once you work at reflection level. For all other purposes (is, casting, passing by value, etc.), it'll "feel" like ParityComprison derives from Comparison<int>.
Users who do reflection are already accustomed to the intricacies of the type system. This will be one more thing to learn.

We can also name them delegate classes, to denote the difference e.g.
public delegate class ParityComparison : Comparison<int>.

I do feel they're necessary for completeness if we have functors, as they're the counterpart of them;
If we have delegate-like classes, it only make sense for us to have class-like delegates :)

[iam3yal]

@YaakovDavis It will probably need a separate proposal though. :)

[MovGP0]

I just had the same idea while playing with implementations of some group theory concepts.

If there is an instance with an .Invoke method, the .Invoke should be optional to type. Example:

var x = a(); // a.Invoke();
var y = a(foo); // a.Invoke(foo);
var z = a(foo, bar); // a.Invoke(foo, bar);

One example, where I use the .Invoke pattern very regularly, is the UnitOfWork (UoW) pattern:

public sealed class SaveCustomerUoW
{
    Func<CustomersContext> CustomersContextFactory { get; }

    public SaveCustomerUoW(Func<CustomersContext> customersContextFactory)
    {
        CustomersContextFactory  = customersContextFactory;
    }

    public void Invoke(Customer customer)
    {
        using(var context = CustomersContextFactory())
        {
            context.Customers.Add(customer);
            context.SaveChanges();
        }
    }
}

// dependency injection of the UoW object
public SomeClass(AddCustomerUoW addCustomer)
{
    AddCustomer  = addCustomer;
}

SaveCustomerUoW SaveCustomer { get; }

Usage:

// currently
SaveCustomer.Invoke(customer);

// with proposed syntax: 
SaveCustomer(customer);

The advantage here is that the UoW can be more easily thought of as a function or method, rather than as an object. It also saves some typing and improves the readability of the code.

[hez2010]

How about using an approach like indexers, and just changing [ ] to ( ):

class Foo
{
    public TR this(T1 p1, T2, p2, ...)
    {
        // ...
    }
}

[HaloFour]

IMO it'd be too similar to indexers and easy to confuse. The compiler is still going to have to emit a named method to permit invocation.

I think the one nice thing about it implicitly using Invoke methods is that it makes something which is currently special-cased for delegate types and makes it a more general purpose feature.