[Proposal]: Improve method overload resolution for covariant value type arrays

[ChristopherHaws]

Improve method overload resolution for arrays

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

The current implementation of method overload resolution seems to treat implicit arrays of value types differently that reference types. I propose that implicit arrays of value types should be treated the same as explicit arrays and implicit arrays of reference types.

Motivation

Why are we doing this?

To prevent the following runtime bug from happening:

void Main() {
    FindAsync(new[] { 1, 2 }, new[] { 3, 4 });                 // 1
    FindAsync(new[] { 1, 2 }, CancellationToken.None);         // 1
    FindAsync(new object[] { 1, 2 }, CancellationToken.None);  // 2
    FindAsync(new[] { "1", "2" }, CancellationToken.None);     // 2
}

public void FindAsync(params object[] keyValues) {
    Console.WriteLine("1");
}

public void FindAsync(object[] keyValues, CancellationToken token = default) {
    Console.WriteLine("2");
}

What use case does it support?

Implicit value type arrays being passed to a method with multiple overloads. This is an issue that currently happens with FindAsync in EF Core:
dotnet/efcore#22667

What is the expected outcome?

The method resolution logic should match that of explicit arrays and implicit reference type arrays.

Detailed design

If a method has multiple overloads, one with params of object[] and one with object[] and a second parameter, the second overload should be used when passing an implicit array and a second parameter that matches the type of the second parameter.

For example, this should be the outcome:

void Main() {
    FindAsync(new[] { 1, 2 }, new[] { 3, 4 });                 // 1
    FindAsync(new[] { 1, 2 }, CancellationToken.None);         // 2
    FindAsync(new object[] { 1, 2 }, CancellationToken.None);  // 2
    FindAsync(new[] { "1", "2" }, CancellationToken.None);     // 2
}

public void FindAsync(params object[] keyValues) {
    Console.WriteLine("1");
}

public void FindAsync(object[] keyValues, CancellationToken token = default) {
    Console.WriteLine("2");
}

Drawbacks

It could break existing code with the very specific scenario of a method having two overloads, one with params of object[] and one with object[] and a second parameter.

Alternatives

This could possibly be an analyzer that warns users that they need to be more specific with their use of an API.

Unresolved questions

None

Design meetings

[CyrusNajmabadi]

i don't think we could change behavior here as there will be code that depends on existing semantics. You could certainly create your own analyzer that warns if you use this pattern if you think it's problematic for your domain.

[svick]

Note that this is not really about "implicit" arrays, the code behaves the same if you explicitly specify the types:

FindAsync(new int[] { 1, 2 }, CancellationToken.None);        // still 1
FindAsync(new string[] { "1", "2" }, CancellationToken.None); // still 2

The difference is caused by array covariance: string[] is implicitly convertible to object[], but int[] is not.

[Joe4evr]

Could probably work around this with a named argument, at least:

FindAsync(new[] { 1, 2 }, token: CancellationToken.None);         // 2

[ChristopherHaws]

Nope, if you do that you will get:

CS1503 Argument 1: cannot convert from 'int[]' to 'object[]'

[svick]

If you're looking for a workaround, one possibility is to make the methods generic and accept T[] instead of object[] (or in addition to it).

[Joe4evr]

@ChristopherHaws Oh whoops, didn't know that.

@svick But the problem with that is that you can't pass an array of mixed types, ie new object[] { 1, "Two" }, which is what these overloads in EF are for.

[svick]

@Joe4evr Why not? object is a perfectly valid T. You can't do new[] { 1, "Two" }, but that's a limitation of C# and no library-level workaround can change that.

[ChristopherHaws]

Thanks for the feedback. I think that the best solution is probably going to have to be a domain specific analyzer.