CS0121 - Inconsistant overload resolution across Roslyn, CSC v12.0, and the mono compilers

Question

I've noticed odd compiler specific enforcement of overload resolution after pulling in the code on a Xamarin project that was being developed exclusively on OSX with Xamarin Studio into a Win 10 box running Visual Studio 2015.2. My curiosity eventually lead me to this post which had the benefit of the attentions of Jon Skeet and Eric Lippert, and was really informative on the subject.

That said, I wanted to play around to see what a minimum replication story would be for this difference between the two compilers, and what I've managed to do is create the following two snippets.

I'll start this off with the Roslyn success case: ​

using System;

public static class Program
{
    public static void Main() { Foo(Bar); } // Outputs Func

    public static void Bar(string input) { Console.WriteLine(input); }
    public static string Bar() { return string.Empty; }

    public static void Foo(Action<string> input) { input("Action"); }
    public static void Foo(Func<string> input) { Console.WriteLine("Func"); }
}

And the case in which Mono will work:

using System;

public static class Program
{
    public static void Main() { Foo(Bar); }

    public static void Bar() { Console.WriteLine("Action"); }

    public static void Foo(Action input) { input(); }
    public static void Foo(Func<string> input) { Console.WriteLine("Func"); }
}

Final recap on compiler versions used:

Roslyn: 1.2.0.60425

v12: 12.0.31010.0

mono: 4.2.3.0

So I'm out of my depth at this point, and my understanding is that the specification is a bit murky about this particular part of how things are handled. Having code that is specific to a compiler to be valid is obviously not the best, so I may just need to request that team members either provide a lambda expression to avoid ambiguity over Method Groups, or at the least an explicit cast.

The Roslyn case is especially odd to me, as it seems that it's decision is the most arbitrary of the selections. Any additional insight would be greatly appreciated.

Edit:

I did manage to find an additional snippet that will successfully compile on both Mono and Roslyn but fail on the v12 compiler:

using System;

public static class Program
{
    public static void Main() { Foo(Bar); }

    public static string Bar() { return string.Empty; }

    public static void Foo(Action bar) { Console.WriteLine("BAR"); }
    public static void Foo(Func<string> input) { Console.WriteLine("Func"); }
}

Answer 1

Okay, I walked away from this for a while, worked on some other things, simplified the usages a little bit more, and I think I've determined the following, with the help of finding this in the specifications.

7.5.3.5 Better conversion target

Given two different types T1 and T2, T1 is a better conversion target than T2 if

• An implicit conversion from T1 to T2 exists

• T1 is either a delegate type D1 or an expression tree type Expression, T2 is either a delegate type D2 or an expression tree type Expression, D1 has a return type S1 and one of the following holds:

  • D2 is void returning

  • D2 has a return type S2, and S1 is a better conversion target than S2

The issue here seems to be that, given the same number of parameters between competing methods in a group, a non-void return type will always be preferred. So given Eric Lippert's example from the aforementioned, what was once a compiler error is now acceptable, assuming it as a single, non-void return type that perfectly matches the expected incoming method group. The odd thing here, though, is even if the void method in the group is the only logical match for the target method's accepted parameters, the method with the return type will be preferred and fail to compile.

So Method groups do seem to consider the return type for selection under Roslyn, so long as, given equal input parameters, only one of the possible members of the method group have a return type other than void

//Fine in Roslyn, not so much in Mono
using System;

public static class Program
{
    public static void Main() { Foo(Bar); } // Outputs Func

    public static string Bar() { return string.Empty; }
    public static void Bar(string s1, string s2, string s3) { }
    public static void Bar(string s1, string s2) {}
    public static void Bar(string s1) { }

    //untick for compile failure
    //public static void Foo(Func<int> input) { }
    public static void Foo(Action<string, string, string> input) { }
    public static void Foo(Action<string, string> input) { }
    public static void Foo(Action<string> input) { }
    public static void Foo(Func<string> input) { Console.WriteLine("Func"); }
}

While Mono seems to have gone in the opposite direction, instead considering the return type to be part of the selection process, which seems to imply that the mono implementation of §7.6.5.1 is different than Roslyns.

//Fine in mono, not so much in Rosyln
using System;

public static class Program
{
    public static void Main() { Foo(Bar); }  // Outputs Func<string>

    public static string Bar(string s1, string s2, string s3) { return "Fail"; }
    public static string Bar(string s1, string s2) { return "Fail"; }
    public static string Bar(string s1) { return "Fail"; }
    public static string Bar() { return "Pass"; }

    // untick for compile failure
    // public static void Foo(Func<string,string,string,string> input) { Console.WriteLine("<string,string,string,string>"); }
    public static void Foo(Func<string> input) { Console.WriteLine("Func<string>"); }
    public static void Foo(Func<int> input) { Console.WriteLine("Func<int>"); }
    public static void Foo(Func<decimal> input) { Console.WriteLine("Func<decimal>"); }
    public static void Foo(Func<char> input) {Console.WriteLine("Func<char>");}
}

And neither will work in the previous compiler version, for the reasons Eric Lippert previously outlined. This was informative to me, at least, although I don't really know what I've learned. I guess don't overload method groups, and if you do, make sure it plays nice with both compilers.