[Proposal] Ambiguous Overload Resolution Priority Hints

[mikernet]

There are some situations where overloads can be ambiguous to the compiler but there is a preference as to which one should be used if both are possible. I propose an OverloadPriorityAttribute that can be used in these situations to pick an overload that should be favored. For example:

[OverloadPriority(1)]
public void ShowFirstItem<T>(IList<T> collection)
{
   Console.WriteLine(collection[0]);
}

[OverloadPriority(0)]
public void ShowFirstItem<T>(IReadOnlyList<T> collection)
{
   Console.WriteLine(collection[0]);
}

var list = new List<int>() { 1 };
ShowFirstItem(list); // picks highest priority ambiguous overload, i.e. IList<T> version

Another situation where this would be useful is situations like this:

[OverloadPriority(1)]
public void SomeMethod<T>(ReadOnlySpan<T> values);

[OverloadPriority(0)]
public void SomeMethod<T>(IEnumerable<T> values);

SomeMethod("value"); // disambiguates to ReadOnlySpan<T> overload
SomeMethod(new int[] { 0, 1, 2 }); // disambiguates to ReadOnlySpan<T> overload

Overload priorities should only be considered when disambiguating methods within the same assembly to prevent cross-library competing for higher priorities. If a method is ambiguous between methods in different assemblies, the ambiguity should remain.

This should also be usable for extension methods:

public static class ListExtensions
{
    [OverloadPriority(1)]
    public void WriteFirstItem<T>(this IList<T> collection)
    {
       Console.WriteLine(collection[0]);
    }
}

public static class ReadOnlyListExtensions
{
    [OverloadPriority(0)]
    public void WriteFirstItem<T>(this IReadOnlyList<T> collection)
    {
       Console.WriteLine(collection[0]);
    }
}

var list = new List<int>() { 1 };
list.WriteFirstItem(); // picks highest priority overload

@333fred @jmarolf @CyrusNajmabadi

[jmarolf]

This should also be usable for extension methods:

Wouldn't this mean adding new classes with these attributes can silently change the meaning of my code?

given a type heirarchy like:

public interface ISomething<T>
{
    T this[int index] { get; }
}

public interface ISomethingElse<T>
{
    T this[int index] { get; }
}

public interface ITheOtherGuy<T>
{
    T this[int index] { get; }
}

public class MyWeirdType<T> : ISomething<T>, ISomethingElse<T>, ITheOtherGuy<T>
{
    public T this[int index] => default(T);
}

Version 1:

using System;

public class C {
    public void M() {
        var list = new MyWeirdType<int>();
        list.WriteFirstItem(); // picks ISomething<T>
    }
}

public static class ISomethingExtensions
{
	[OverloadPriority(1)]
    public static void WriteFirstItem<T>(this ISomething<T> collection)
    {
       Console.WriteLine(collection[0]);
    }
}

public static class ISomethingElseExtensions
{
	[OverloadPriority(0)]
    public static void WriteFirstItem<T>(this ISomethingElse<T> collection)
    {
       Console.WriteLine(collection[0]);
    }
}

Version 2 or Someone adds a nuget package etc...:

using System;

public class C {
    public void M() {
        var list = new MyWeirdType<int>();
        list.WriteFirstItem(); // picks ITheOtherGuy<T> silently
    }
}

public static class ITheOtherGuyExtensions
{
	[OverloadPriority(2)]
    public static void WriteFirstItem<T>(this ITheOtherGuy<T> collection)
    {
       throw new InvalideOperationException();
    }
}

public static class ISomethingExtensions
{
	[OverloadPriority(1)]
    public static void WriteFirstItem<T>(this ISomething<T> collection)
    {
       Console.WriteLine(collection[0]);
    }
}

public static class ISomethingElseExtensions
{
	[OverloadPriority(0)]
    public static void WriteFirstItem<T>(this ISomethingElse<T> collection)
    {
       Console.WriteLine(collection[0]);
    }
}

This would mean that any change in type visibility could silently change which overloads are chosen for a given method.

[jmarolf]

If these were allowed on extension methods the potential for source-breaking changes would be unlimited right? Would we instead want to limit them to just the original type?

[mikernet]

The "adds a nuget" wouldn't apply because if the ambiguity was between 2 assemblies it would still be an ambiguity, as stated in the OP.

[mikernet]

But yes, if you changed the overload priority within your own assembly then that could change overload resolution.

[AraHaan]

My 🧠 compiler says that the IList overload in the 2 example codes would always be used (and called at runtime) over the IReadOnlyList version (even for extension methods). And same for the other example above with an ReadOnlySpan and IEnumerable overloads.

It would be a win/losing race since usually there are implicit conversions to ReadOnlySpan so the ReadOnlySpan for sure might always win 100% of the time.

[mikernet]

@AraHaan They both result in an ambiguous method error, hence this issue.

[cheong00]

Just want to put DefaultOverloadAttribute and OverloadAttribute be used in Windows Runtime API into picture.

[DavidArno]

I'd love to see something like this added to the compiler to help resolve method ambiguities. Currently, I use the approach of "further away" namespaces to lower the priority of more generic methods:

namespace A.B.C.D
{
    public static class EnumerableExtensions
    {
        public static IFoo<T> GetFoo<T>(this IEnumerable<T> item) => new EnumerableFoo<T>(item);
    }
}

namespace A.B.C
{
    public static class ListExtensions
    {
        public static IFoo<T> GetFoo<T>(this IList<T> item) => new ListFoo<T>(item);
    }
}

Being able to do away with multiple files in multiple namespaces and put it all in one file would be a lot tidier as it always feels like a hack to make use of namespaces like this:

namespace A.B.C
{
    public static class AllOfTheExtensions
    {
        [OverloadPriority(0)]
        public static IFoo<T> GetFoo<T>(this IEnumerable<T> item) => new EnumerableFoo<T>(item);

        [OverloadPriority(1)]
        public static IFoo<T> GetFoo<T>(this IList<T> item) => new ListFoo<T>(item);
    }
}

[mikernet]

These resolve fine for me. IList<> implements IEnumerable<> so it always picks the IList<> overload if the object implements both. The issue only comes up with IReadOnlyXyz interfaces since they aren't part of the IXyz hierarchy.

[alrz]

Doesn't shapes solve this problem?

    public void WriteFirstItem<T>(this T collection) where T : Indexable
    {
       Console.WriteLine(collection[0]);
    }

Or just add WriteFirstItem<T>(this List<T> list) => WriteFirstItem((IList<T>)list);

In my opinion OverloadPriorityAttribute seems like a costly overkill compared to alternatives.

[bernd5]

It looks not bad for single element parameter lists - but what is with multiple parameters? Then the OverloadPriority attribute becomes messy.

[alrz]

The overload resolution in those cases is already almost unpredictable depending on parameters and arguments. Adding another layer of tie breaker will just complicate the whole thing on top of everything else - because you probably don't want to change the meaning of the valid code by adding such attributes.

If you wish to not type a cast to select the desired overload, you could always use a helper or a different name.

Yes, any of the above is at best a "workaround" but so is OverloadPriorityAttribute (IMO). At least we have those today, any other solution is unlikely to beat those that are currently available in terms of ETA.

[AraHaan]

I agree with this, having said priority to allow ambiguous overload resolutions on methods because samples sent in this discussion will always have one that will always be used over the others as that one will always win no matter what.

[mikernet]

Adding overloads for every specific collection type isn't really feasible in a lot of cases. I have custom collections that implement IDictionary and IReadOnlyDictionary in a collections assembly. I don't want to add a reference to that in the extensions assembly with a bunch of specific overloads just so that I can use those collections without casts.

Shapes aren't entirely analogous here either. They would depend on the type having public members that match the signature of the methods in question, but custom collections often explicitly implement interface members and provide different public signatures for the equivalent methods.

[jnm2]

Duplicate of #964 and #4869?

[mikernet]

Indeed, appears as though it is. Perhaps merging would be appropriate?

In regards to a tie-breaker between 3+ overloads, I could see this happening:

[OverloadPriority(0)]
public void Method<T>(IEnumerable<T> list);
[OverloadPriority(1)]
public void Method<T>(IReadOnlyList<T> list);
[OverloadPriority(2)]
public void Method<T>(IList<T> list);
[OverloadPriority(3)]
public void Method<T>(ReadOnlySpan<T> span);

Method("string"); // pick ROSpan
Method(new int[] { 1, 2, 3 }); // pick IList

Side note: Why doesn't String implement IList/IROList?

[CyrusNajmabadi]

Side note: Why doesn't String implement IList/IROList?

Increased metadata bloat for a core type that probably never needs to be used in a situation where you have a IROList<char> requirement. :)

Whereas IEnumerable<char> allows string to be used by the entire Linq api.

[mikernet]

LINQ optimizes for IList though :) Would make some things quicker.

[CyrusNajmabadi]

LINQ optimizes for IList though :) Would make some things quicker.

6 of one, a half dozen of another.

[dmccarty-incomm]

This feature was precisely what I came here to propose. I recently brought it up on Stack Overflow and it was not well received there, but the more I think about it, the more I think it could be a nice feature. The primary arguments against it are

1. We don't need that. Here are some existing work-arounds you could use instead...
2. If you use this wrong, it could cause horrible bugs and make you sad

Yes, both of those are true. We DO have work-arounds that make this not strictly necessary and if you abuse it, you could cause problems, but aren't both of those statements true about an awful lot of other things that wind up getting implemented, anyway? Doesn't the ability to write code that is cleaner, more concise, and/or easier to consume very often warrant new features? As for the second concern, there are far more "dangerous" features that have been around forever (implicit operator overloading comes to mind) that are there because when used correctly, they make things much easier. If a user has gone to the effort of adding an overload resolution hint, then it is safe for the compiler to assume they have thought about it and have concluded that it is the best move and at this point, any bugs introduced are the responsibility of the developer. This argument feels a bit like not being able to buy a saw at a hardware store because you might cut yourself with it. (Side note: I've been trying to come up with a use case where this would cause problems, but would not have been obvious during coding and have not been able to think of anything. Either there is no problem at all, or you practically have to be trying to cause a problem.)

It is a common programming pattern to have a single function that does some work for you and then to add several overloads that accept a different shape of data as input and simply transform that input into a shape that the original function can accept. This gives the consumer of the function a single method name to remember when trying to perform that action. As it is now, once there is an ambiguity, they have to remember slight variations on the name of the function, transform the data input at the call, pass in parameters that could otherwise have been optional, or do some other similar not-a-big-deal-but-could-be-better actions. At least in this pattern, if there is ever an ambiguity between any of these overloads, then it usually doesn't really matter which path it takes on its way to the main function because ambiguity implies that any of the candidates could transform the data into a form it can understand.