Inferring delegate types for _lamdba_expressions_ and method groups through implicit conversion operators.

[mwadams]

There have been considerable improvements in lamdba_expressions type inference in recent versions of C#.

For example, given this type

public delegate void Delegate1(ref Callback1 b);

public ref struct Callback1
{
   public void Add(string value) {}
}

public delegate void Delegate2(ref Callback2 b);

public ref struct Callback2
{
   public void Add(int value) {}
}


public static class SomeClass
{
  public static void TestMethod(
      Delegate1 value)
  {
  }

  public static void TestMethod(
      Delegate2 value)
  {
  }
}

it is now possible to resolve (using LangVersion preview at the time of writing)

SomeClass.TestMethod(static (ref b) => b.Add("Hello"));

However, if we introduce a union-like type:

public readonly struct Source
{
    // Poor-developer's union
    private readonly Delegate1? _d1;
    private readonly Delegate2? _d2;
    private readonly int _someInt;

    private Source(Delegate1 d1)
    {
        _d1 = d1;
    }

    private Source(Delegate2 d2)
    {
        _d2 = d2;
    }

    private Source(int someInt)
    {
        _someInt = someInt;
    }

    public static implicit operator Source(Delegate1 d1) => new(d1);
    public static implicit operator Source(Delegate2 d2) => new(d2);
    public static implicit operator Source(int someInt) => new(someInt);
}

And replace our TestMethod() with that union-like type:

public static class SomeClass
{
    public static void TestMethod(
        in Source value)
    {
    }
}

We can no longer implicitly resolve the lambda_expression to a specific delegate type, because it cannot make the double hop through the baked-in implicit conversion to a delegate type, and then the implicit conversion operator on the Source type.

This forces us through the ugly mechanism of making our delegate constructors public and wrapping the lambda_expression in a new(). (Or a cast to the delegate type which is probably even more ugly. YMMV! :) )

public readonly struct Source
{
    // Poor-developer's union
    private readonly Delegate1? _d1;
    private readonly Delegate2? _d2;
    private readonly int _someInt;

    public Source(Delegate1 d1)
    {
        _d1 = d1;
    }

    public Source(Delegate2 d2)
    {
        _d2 = d2;
    }

    private Source(int someInt)
    {
        _someInt = someInt;
    }

    public static implicit operator Source(int someInt) => new(someInt);
}

SomeClass.TestMethod(new(static (ref b) => b.Add("Hello")));
SomeClass.TestMethod(32);

As was pointed out elsewhere, the blocker to this is actually that implicit conversions are (completely consistently) not considered when resolving target types. Which results in the same problem if you supply a method group, too (as there is a need for a hidden implicit conversion to the delegate type in that case too.)

However, I'm not approaching this suggestion from the "underlying mechanism" perspective - but from the "how you express your code in the language" perspective. Whatever the underlying mechanism, this would be considerably more concise and expressive.

I note that this would have the same issues given the v. future union language features as currently conceived.

[mwadams]

I guess it is also interesting to note that the extra level of indirection is effectively resolved by the "new" wrapper. It is the "bridge" that lets us do inference right up the stack so we don't actually have any type names in that final example. But it would be great if the compiler could infer that bridge for us.