Confusion with method groups

[vnesterovsky]

Recently, I typed a line of C# code that did not compile, though I wish compiler to understand it.

Consider a following snapshot:

static bool Run(string arg) => true;

var Run2 = Run;

void F()
{
  var s1 = Run;  // This compiles.
  var s2 = Run2; // This compiles.

  var tuple1 = ("Run", Run);  // This does not compile.
  var tuple2 = ("Run", Run2); // This compiles.

  var (name1, func1) = ("Run", Run);  // This does not compile.
  var (name2, func2) = ("Run", Run2); // This compiles.
}

It's clear that the C# compiler stumbles dealing with method groups.

I would like for the following lines to be valid:

static bool Run(string arg) => true;

var tuple = ("Run", Run);

It would be good for C# compiler to be able to coerce a method group with single member as a lambda, thus to avoid unnecessary code.

What do you think?

[jnm2]

This also seems to be specific to some things (tuples, conditional expressions) and not other things (e.g. var arr = new[] { Run };, inferring generic method arguments). This is interesting:

static bool Run(string arg) => true;

void F()
{
    var tuple1 = ("Run", PassThrough(Run)); // Works
}

static T PassThrough<T>(T v) => v;

[vnesterovsky]

I came to different workarounds as well, but my goal was to point that that code becomes unnecessary complex.

[jnm2]

The reason why any of those usages of Run works is https://github.com/dotnet/csharplang/blob/main/proposals/csharp-10.0/lambda-improvements.md. It has a section that seems to explain what you're showing:

Function_types are used in a few specific contexts only:

• implicit and explicit conversions
• method type inference (§11.6.3) and best common type (§11.6.3.15)
• var initializers

By doing a git blame, I found the PR which documented this decision, which very helpfully had a link to the meeting notes which decided this approach, but what was discussed was only immediately-invoked function members. It's not clear if the concluding list of limitations was only derived from blocking IIFEs or if it was a continuation from some other meeting where these limitations were discussed.

[jnm2]

There's other things, like conditional expressions: var x = cond ? Run : Run2; which don't work.

[RikkiGibson]

I might be missing some of the motivation/context, but I'm personally not a fan of having to enumerate the set of contexts that a function_type can be used in. It feels like this natural type should be used in any context that a lambda or method group appears in.

It sounds like we have reasons for wanting to block IIFEs--that's fine. Don't change the type rules, just make it an error if an unconverted lambda or method group is used as the receiver of a call. We can still understand and expose the natural type of the receiver, e.g. in the editor and public APIs. That seems like much less of a contortion of the rules.

[jnm2]

@RikkiGibson Think we should clarify the spec, maybe consider it a compiler bug that var x = (1, MethodGroup); doesn't work?

[CyrusNajmabadi]

@RikkiGibson agreed.

[siegfriedpammer]

I wanted to add one case where I recently stumbled across this:

using System;
public class C {
    void DynamicCall(dynamic method) => method(42);
    
    public void M() {
        void Local(int x) => Console.WriteLine(x);
        DynamicCall(Local); // error CS1503: Argument 1: cannot convert from 'method group' to 'dynamic'
        
        var f = Local;
        DynamicCall(f); // works fine
    }
}

If these cases are declared a compiler bug, then dynamic should not be left out for the sake of completeness.