Proposal: Implicit overloads for return value overloading

[hez2010]

Background

Currently, we have a lot of APIs that are not modernized, for example, GetEnumerator which returns a non-generic collection, the non-generic Groups property in regex matching result, and the string.Split() which returns a string[] instead of ReadOnlySpan<ReadOnlySpan<char>> (should be possible after we support ref structs in generic arguments).

We cannot just create a new overload with different return value types in C# today, but fortunately, CIL supports overloading by return values, and we are including return values in the signature and taking it into account while doing method lookup.

Overloading by return values

We can enable overloading by return values to allow a method to be overloaded by the type of return value.

class Match
{
    GroupCollection Groups { get; }
    // ambiguity
    ReadOnlySpan<Group> Groups { get; }
}

But this soon makes adding an overload a source breaking change as the compiler can no longer figure out which method to use if the receiver is implicitly typed (such as var).

Implicit overloads

We can resolve the above issue by introducing implicit overloads:

class Match
{
    [ImplicitOverload]
    GroupCollection Groups { get; }
    ReadOnlySpan<Group> Groups { get; }
}

If the receiver is implicitly typed (like var), the compiler then picks the implicit one to ensure the existing usage won't break. If the receiver is explicitly typed, it follows the existing overload resolution rules to pick the best one.

var groups = match.Groups; // GroupCollection

foreach (var group in match.Groups)
{
    // use implicit overload for Groups which is a GroupCollection
}

Span<Group> groups = match.Groups; // Span<Group>

foreach (Group group in match.Groups)
{
    // use the Span<Group> one for Groups
    // this can also avoid an implicit cast from object to Group
}

[KennethHoff]

Feels related to (but in no way duplicates) #7706

[HaloFour]

I wonder how overload resolution would work today if the C# compiler encountered an assembly written in a language that does permit overloading based on return type. I assume it wouldn't be able to pick which overload and it would emit an error about ambiguous overloads.

Given how complicated overload resolution already is I'm loathe to have the potential target type potentially influence that, especially with type coercion and all of those other rules that affect those systems.

[HaloFour]

Yep, ambiguous overload error:

CS0121: The call is ambiguous between the following methods or properties: 'Class1.M()' and 'Class1.M()'

[iam3yal]

It might be possible to use the keyword default as opposed to an attribute? to indicate that this should be the one to be picked. Just a thought.

[sab39]

I think that if we allowed overloading on return type with the restriction that the new proposed OverloadResolutionPriority attribute must be used to disambiguate, you could achieve the desired result by giving the ReadOnlySpan version a higher priority, and then adding an implicit conversion from ReadOnlySpan<Group> to GroupCollection so that explicitly typed uses would continue to compile. Always nice when existing proposals can be combined or used to create something beyond the sum of their parts!

[TahirAhmadov]

@hez2010 can you please provide another example where this is useful? I'm not sure the regex match groups is a good candidate - unless I'm missing something.