Overload Resolution via Return Types

[TonyValenti]

When #7706 gets implemented, I will be able to control which overloads the compiler picks. However, this does not solve one problem: allowing me to pick a method that varies only by return type. ie:

        public static string? Test() {
            return default;
        }

        public static int? Test() {
            return default;
        }

In conjunction with #7706, the language should allow methods to vary by only return type.

Selecting the Correct Method via Type Inferencing

The correct method can be selected via Type Inferencing where the context permits. For example:

public static void Invoke(string? Input) { }

Invoke(Test());

and:

string? Value = Test();

will automatically select public static string? Test()

Selecting the Correct Method via Hints

In the event that an ambiguity still exists, a 'hint' can be provided that allows selecting the preferred overload.
Hints look just like a cast:

AmbiguousInvoke( (string?)Test());
AmbiguousInvoke( (int?)Test());

If you want to cast the value of the abiguous method, you'll 'cast' it twice

var Value = (double?)(int?)Test();

Discussion

The double cast syntax might seem odd at first, but the language already requires this is some situations. Specifically when working with generics:

var Test = new T();
var ret = (T)(object)Test; //Double cast is already required

There is also zero chance that the double-cast syntax will conflict with cause issues with existing code because methods that only vary by return type currently do not exist.

[HaloFour]

It's interesting, and technically possible, but given that overloading is already super convoluted, influenced by all kinds of type coercion rules, I can't imagine that it's worth adding the complexity of trying to also disambiguate candidates through different return types.

What are the use cases for supporting something like this? I don't think you'd design a public API that would use a feature like this. IMO I think the only use cases where it might be useful is where you want to deprecate an API and replace it with another one, but don't want to break existing clients.

[TonyValenti]

@HaloFour - That is exactly the scenario. This be super useful when upgrading APIs to use more performant types. For example, converting methods that return Task to ValueTask and Arrays to Spans. Yes - you could always introduce a method called {Method}AsValueTask or {Method}AsSpan but that would be a big code smell.

[hez2010]

It's pretty useful. For example, once we decide to add 64 bit storage for Array, List and etc. We can overload the Length property to use nint instead of int, while keeping the original Length property with a hidden attribute for back-compact.

Worth to note that overloading by return types is allowed in IL, so no metadata breaking change is required here.