[Proposal][Delegate Enhancement] Allow return multiple results from Delegate

[redradist]

Issue

Consider the following code:

using System;

class Program
{
    delegate int Operation(int x, int y);
         
    static void Main(string[] args)
    {
        Operation del = Add;
        del += Multiply;
        int result = del(4, 5);
        Console.WriteLine(result);
         
        Console.Read();
    }
    
    private static int Add(int x, int y)
    {
        return x+y;
    }
    
    private static int Multiply (int x, int y)
    {
        return x * y;
    }
}

There problem with this solution is that del returns only last result

Proposal

Consider different behavior for different assignment variables:

using System;
using System.Collections.Generic;

class Program
{
    delegate int Operation(int x, int y);
         
    static void Main(string[] args)
    {
        Operation del = Add;
        del += Multiply;
        // Lets infer what user tries to achieve
        {
            List<int> results = del(4, 5);
            foreach (var res in results)
            {
                Console.WriteLine(res);
            }
        }
        // Or
        {
            IEnumerable<int> results = del(4, 5);
            foreach (var res in results)
            {
                Console.WriteLine(res);
            }
        }
        
        Console.Read();
    }
    
    private static int Add(int x, int y)
    {
        return x+y;
    }
    
    private static int Multiply (int x, int y)
    {
        return x * y;
    }
}

How it will work ?? Under the hood it will work as follows:

using System;
using System.Collections.Generic;

class Program
{
    delegate int Operation(int x, int y);
         
    static void Main(string[] args)
    {
        Operation del = Add;
        del += Multiply;

        // Below compiler generated code
        {
            List<int> results = new List<int>();
            foreach (var method in del.GetInvocationList())
            {
                results.Add((int) method.DynamicInvoke(4, 5));
            }
        }
        // Or
        {
            IEnumerable<int> results = del?.GetInvocationList().Select(x => ((Operation)x)(4, 5));
        }

        foreach (var res in results)
        {
            Console.WriteLine(res);
        }
        
        Console.Read();
    }
    
    private static int Add(int x, int y)
    {
        return x+y;
    }
    
    private static int Multiply (int x, int y)
    {
        return x * y;
    }
}

If left hand side object is a Collection Type or IEnumerable Type then it can be used as storage for results from delegate invocation

[HaloFour]

Reinterpreting the invocation based on assignment would be fragile and likely break existing code. I can't see that being considered without a separate syntax at the callsite.

This is also a "problem" very easily remedied with extension methods that manually unwrap the delegate into an invocation list. I'd also simply suggest not relying on multicast delegates to return values.

[markusschaber]

I think this is a corner case which does not warrant a language change. However I'd vote for having a set of extension methods, if possible, in the standard library, or a NuGet package.
(And if it's not possible, we might need to have a look into why not, and maybe provide the language change there... :-) )

[redradist]

@HaloFour Hi Halo,

You wrote:

Reinterpreting the invocation based on assignment would be fragile and likely break existing code. I can't see that being considered without a separate syntax at the callsite.

It is not breaking changes, because I propose to change invocation based on assignment only in case of calling delegate object.
In all other case behavior stay the same

This is also a "problem" very easily remedied with extension methods that manually unwrap the delegate into an invocation list. I'd also simply suggest not relying on multicast delegates to return values.

Yes, it is solvable with extension method, but it is not user-friendly to use. Better to hide it with Syntax Sugar like in my Proposal

[DaZombieKiller]

@redradist

Yes, it is solvable with extension method, but it is not user-friendly to use. Better to hide it with Syntax Sugar like in my Proposal

I wrote a bunch of extension methods for this purpose a while ago #1426 (comment)

What's wrong with this?

using System;
using System.Collections.Generic;

class Program
{
    static void Main(string[] args)
    {
        Func<int, int, int> func = Add; func += Multiply;
        IEnumerable<int> results = func.InvokeAll(4, 5);

        foreach (int result in results)
            Console.WriteLine(result);

        Console.Read();
    }
    
    static int Add(int x, int y) => x + y;
    
    static int Multiply(int x, int y) => x * y;
}

[redradist]

@redradist

Yes, it is solvable with extension method, but it is not user-friendly to use. Better to hide it with Syntax Sugar like in my Proposal

I wrote a bunch of extension methods for this purpose a while ago #1426 (comment)

What's wrong with this?

using System;
using System.Collections.Generic;

class Program
{
    static void Main(string[] args)
    {
        Func<int, int, int> func = Add; func += Multiply;
        IEnumerable<int> results = func.InvokeAll(4, 5);

        foreach (int result in results)
            Console.WriteLine(result);

        Console.Read();
    }
    
    static int Add(int x, int y) => x + y;
    
    static int Multiply(int x, int y) => x * y;
}

Nothing wrong with it, but it is not supported directly by the language and it is sad

[markusschaber]

A feature which can easily emulated with existing language tools does not necessarily need a language change.

[AlgorithmsAreCool]

You say the left hand side must be a collection type, you'll need to specify exactly what qualifies as a collection type and how the compiler would populate it.

This is incurring a big performance hit from the List allocation. A struct enumerator would probably a better performing option. You could lobby in coreclr to get it added natively to Delegate.

Also, Multicast delegates were a mistake

[Gnbrkm41]

Try

IEnumerable<int> results = del?.GetInvocationList().Select(x => ((Operation)x)(left, right));

?

Nothing wrong with it, but it is not supported directly by the language and it is sad

It seems like a relatively niche usage of delegates to me, personally I think it would be confusing to embed such feature to the language(int a = del(left, right); IEnumerable<T> b = del(left, right);?). I'd vote for an extension method if it were to be added.

[redradist]

@AlgorithmsAreCool You wrote:

Also, Multicast delegates were a mistake

I agree with you, but unfortunately we have what we have ... Backward compatibility ! (

[svick]

@redradist Backwards compatibility means the feature can't be removed. But what is the reason to make it easier to use? If it's hard to use, hopefully less people will use it, making the negative effects of those mistakes smaller.

[redradist]

@Gnbrkm41

Try

IEnumerable<int> results = del?.GetInvocationList().Select(x => ((Operation)x)(left, right));

?

Nothing wrong with it, but it is not supported directly by the language and it is sad

It seems like a relatively niche usage of delegates to me, personally I think it would be confusing to embed such feature to the language(int a = del(left, right); IEnumerable<T> b = del(left, right);?). I'd vote for an extension method if it were to be added.

Yes, man I exactly taking about the same solution !!
But why compiler cannot emit the same piece of code ?!

Instead of writing the following:

IEnumerable<int> results = del?.GetInvocationList().Select(x => ((Operation)x)(left, right));

Compiler could emit the following code:

IEnumerable<int> results = del(left, right);
// Under the hood it will call the following code as previously
// IEnumerable<int> results = del?.GetInvocationList().Select(x => ((Operation)x)(left, right));

@HaloFour @Gnbrkm41
What is wrong with such feature ??

[theunrepentantgeek]

What is wrong with such feature ??

This is the wrong question. The question should be

What is right with such feature?

Remember that every feature starts at -100 points and needs to provide copious obvious value just to reach a threshold worth considering.

As far as I'm aware, multicast delegates are pretty much used only by UX frameworks like WinForms and WPF, and even within that subset of development, multicast delegates that return a value are outstandingly rare.

My experience is that I've never written nor reviewed any code that uses multicast delegates with return values.

Given that you've already got a one line way to achieve what you want, the value in adding it to the language is minimal, at best.

You'd get much further going to the corefx repo and suggesting the addition of an overload to GetInvocationList() that doesn't need the cast. (IIRC, the existing GetInvocationList() predates generics.)