Simplify method call when using delegates (like LINQ)

[Enderlook]

Sorry for the weird title, I'm not sure how to name it.

Imagine this current working code:

using System.Collections.Generic;
using System.Linq;

public class Foo {
    public object InstanceBar() => null;
    public static object StaticBaz(Foo foo) => foo.Bar();
}

public class Test {
    public IEnumerable<object> Works(IEnumerable<Foo> foos)
        => foos.Select(e => e.InstaceBar());
    
    public IEnumerable<object> AlsoWorks(IEnumerable<Foo> foos)
        => foos.Select(Foo.StaticBaz);
}

Wouldn't be nice if you could do?:

public class Test {
    public IEnumerable<object> Error(IEnumerable<Foo> foos)
        => foos.Select(Foo.InstanceBar);
}

or even:

public class Test {
    public IEnumerable<object> Error(IEnumerable<Foo> foos)
        => foos.Select(InstanceBar);
    
    public IEnumerable<object> AlsoError(IEnumerable<Foo> foos)
        => foos.Select(StaticBaz);
}

The compiler could infer what you are trying to call and generate the corresponding code like currently does.

Maybe with the instance version (either foos.Select(Foo.InstanceBar) or foos.Select(InstanceBar)) the compiler-generated class could be avoided. However, I don't know if the CLR supports that. Anyway, there is no need for the optimization, the syntactic sugar is very nice and readable by itself.

What do you think?

[jnm2]

Similar: #91, #602

[ntovas]

I believe that the foos.Select(Foo.InstanceBar) proposal is not following the language's specifications and it will be a very bad hack if implemented.

For the foos.Select(InstanceBar) i believe that there is a chance but imho it reduces readability, also there may be cases of another method with the same name in Test class of your example, and then its hard for the compiler and the programmer to understand the intent.