Inferred variable initializer should attempt to resolve extension before trying to infer natural function type

[jcouv]

Reported in dotnet/csharplang#9517 by @LeQuackers
Needs to be confirmed with WG, but if resolving extensions yields something other than a method, then we should be done (no need to infer natural function type).

    [Fact]
    public void TODO2()
    {
        var src = """

public static class Extensions
{
    extension(C c)
    {
        public int M => C.M();
    }
}

public class Test
{
    public static void Foo()
    {
        var upper = new C().M; // error CS8917: The delegate type could not be inferred.
    }
}

public class C
{
    public static int M() => 0;
}
""";
        var comp = CreateCompilation(src);
        comp.VerifyEmitDiagnostics(
            // (14,21): error CS8917: The delegate type could not be inferred.
            //         var upper = new C().M; // error CS8917: The delegate type could not be inferred.
            Diagnostic(ErrorCode.ERR_CannotInferDelegateType, "new C().M").WithLocation(14, 21));
    }

[jcouv]

Will confirm with WG, but I believe this behavior is by-design. The non-extension method hides the extension property, despite not being applicable to the receiver because it's static.

The analogous non-extension scenario is:

        src = """
var x = new C().M;
System.Console.Write(x);

public class Base
{
    public int M => 42;
}

public class C : Base
{
    public static int M() => throw null;
}
""";
        comp = CreateCompilation(src);
        comp.VerifyEmitDiagnostics(
            // (1,9): error CS8917: The delegate type could not be inferred.
            // var x = new C().M;
            Diagnostic(ErrorCode.ERR_CannotInferDelegateType, "new C().M").WithLocation(1, 9),
            // (11,23): warning CS0108: 'C.M()' hides inherited member 'Base.M'. Use the new keyword if hiding was intended.
            //     public static int M() => throw null;
            Diagnostic(ErrorCode.WRN_NewRequired, "M").WithArguments("C.M()", "Base.M").WithLocation(11, 23));

[LeQuackers]

@jcouv

I gave the scenario you mentioned a look and I think the direction of inheritance is backwards when compared to the original extension property example.

In your example Base defines the property and C defines the static method, but for extension properties it reversed; Base would define the existing static method and C would define the property:

var x = new C().M; // Works fine.
System.Console.Write(x);

public class Base
{
    public static int M() => throw null;
}

public class C : Base
{
    public int M => 42; // CS0108 'C.M' hides inherited member 'Base.M()'. Use the new keyword if hiding was intended.
}

Also, I played around with it a bit more and extension properties allow the new keyword, but it doesn't appear to do anything when applied.

[jcouv]

@LeQuackers I included the property in the base rather than the derived type so that it comes after the static method, in a similar way that extension members come after non-extension members.
The rule for lookup is that by walking up the base hierarchy we find the first member with the proper name, and 1. if it's a non-method we're done, 2. if it's a method we collect the remaining methods into a method group, 3. if it's a mix, we have an ambiguity.
In the OP scenario, we've already determined that we're dealing with a method group, and so a property that comes later cannot change that.

[LeQuackers]

@jcouv

Ah, that makes more sense, but that's also a bit unfortunate to hear. I guess I never noticed it because it was all extension methods before, which got collected/resolved in the method group stage. I assumed extension properties would take priority in resolution because extensions are often used to extend the capabilities of 3rd party types; a developer writing an extension property in their own project would probably expect it to take priority in their own project, otherwise they wouldn't have written it.

---

For some context and as a practical example, my work has a lot of .NET 4.8 stuff that we're trying to move to .NET Core, but we need to move as much code as possible to .NET Standard 2.0 first to ensure backwards/forwards compatibility and unit test against old and new versions. We do a lot of stuff with char, string, and DateTimeOffset in particular, so having some extensions to handle common checks/procedures is beneficial for various reasons. One example is a bool IsAscii { get; } instance extension property on char, which would cleanup a lot of spots. It works fine in the .NET 4.8 and .NET Standard 2.0 versions, but fails in .NET Core because the char.IsAscii(char) static method exists in later versions.

Extensions allow developers to add new functionality to existing types without modifying its source code or creating new derived types, and this feature develops that ability even more, but at the moment there's a risk that your own code will break in your own projects if said 3rd party adds a method of the same name in the future (i.e. minor version updates have the potential to break your code now), which can lock you into deprecated package versions if you're not careful.