[Proposal] Overload resolution hint for overloads that have exactly the same priority

[gafter]

@ashmind commented on Thu Oct 01 2015

Problem

There are cases when there is need for two overloads that perform a same function over different types.
Example:

TValue GetValueOrDefault<TKey, TValue>(this IDictionary<TKey, TValue> dictionary, TKey key);
TValue GetValueOrDefault<TKey, TValue>(this IReadOnlyDictionary<TKey, TValue> dictionary, TKey key);

This pattern breaks when something belongs to both types, e.g. d.GetValueOrDefault would break if d is a Dictionary<,>, since it implements both interfaces. There is no good workaround other than forcing user to cast, or implementing additional overloads for common types.

Another case (more of an edge case) I had recently was

bool operator==(MyType x, OtherType1 y);
bool operator==(MyType x, OtherType2 y);

which breaks on a common case of x == null as null can belong to either type.

Proposal

I feel that in most of those cases it does not matter which overload will be selected for types that match both -- as long as it is actually selected and user does not have to cast.

So the suggestion is to provide a hint to the compiler -- specifying which overload to pick when all of them have exactly the same priority.

To avoid polluting the language, I suggest an attribute, e.g.:

TValue GetValueOrDefault<TKey, TValue>([PrimaryOverload] this IReadOnlyDictionary<TKey, TValue> dictionary, TKey key);

bool operator==(MyType x, [PrimaryOverload] OtherType1 y);

Not sure what would be the best name -- open to feedback.

---

@MgSam commented on Thu Oct 01 2015

What happens in the inevitable situation when multiple methods both specify PrimaryOverload? You're back in the same situation as today. Maybe an integer (or double) OverloadPriority() attribute works better. Then, like with z-order in graphics, anyone can come in and pick one that's appropriate to give them the behavior they want.

---

@ashmind commented on Thu Oct 01 2015

What happens in the inevitable situation when multiple methods both specify PrimaryOverload? You're back in the same situation as today.

Not quite. Today the API developer has no control over overload selection in cases like IDictionary vs IReadOnlyDictionary. There is literally no good way for the API to provide that. What I want is to give some control to API developer, making life easier for API users (no cast required).

What you are saying is API developers might mess up their chance at making things right. Well, yes, but it would be a fixable mess up, while right now there is no API-side solution.

---

@ashmind commented on Thu Oct 01 2015

Maybe an integer (or double) OverloadPriority() attribute works better.

I want to avoid this as the suggestion is only for case where overloads have exactly the same priority. Providing a numeric priority would be confusing with regards to other (e.g. type-based) priority rules.

Just to be clear, I don't want a way to prioritize my method over someone else's methods or extension methods. The main goal is to prioritise within a set of methods you own.

---

@MgSam commented on Fri Oct 02 2015

@ashmind You reference DLL A, which contains TValue GetValueOrDefault<TKey, TValue>(this IDictionary<TKey, TValue> dictionary, TKey key). Author A has decorated it with your proposed attribute.

You reference DLL B, which contains TValue GetValueOrDefault<TKey, TValue>(this IReadOnlyDictionary<TKey, TValue> dictionary, TKey key). Author B has also decorated it with your proposed attribute.

Which one gets selected by overload resolution? You're in the same situation you are today.

Now you could say that this feature only applies to declared in the same assembly- that might be a reasonable compromise.

---

@ashmind commented on Fri Oct 02 2015

@MgSam You are right, two libraries can conflict. But it's not new -- it's already a conflict even without attributes. It's even likely that two authors with same goals make the same methods (IDictionary<,>.GetValueOrDefault in both, for example).

Same as now, these conflicts are resolved by library users who decided to install both, e.g. through imports.

Now you could say that this feature only applies to declared in the same assembly- that might be a reasonable compromise.

That would only be important if one author used the attribute, and other didn't -- not sure it's worth an extra rule. If both used the attribute, the result of ignoring attribute is same as supporting it -- ambiguity.

---

@gafter commented on Mon Oct 05 2015

@ashmind Can you please be more specific about what you mean by "priority"? Is this an early tie-breaker or a late tie-breaker? More generally, exactly where in the overload resolution process would this affect the result? Is it intended to apply when neither of two methods are more specific than the other, or when both of two methods are as specific as each other, or in both of these circumstances?

---

@ashmind commented on Mon Oct 05 2015

@gafter There are two options I considered, either of which will cover the use cases.
I think first option is probably the best, as it is the simplest, but the second one might represent the intent better.

In either option, I am not fond of the attribute name — any suggestions are welcome.

Member-level (simplest)

If we say the the attribute goes on the methods themselves, then the syntax would be

[BetterOverload] void M(X x);
void M(Y y);

Then to handle it, in C# 5.0 Specification (haven't found 6.0), 7.5.3.2 Better function member, immediately before

• Otherwise, neither function member is better.

we add

• Otherwise if one member is annotated with BetterOverloadAttribute, and other is not annotated with BetterOverloadAttribute, the annotated one is better.

Parameter-level

If we say that attribute goes on the parameters, then the syntax would be

void M([BetterOverload] X x);
void M(Y y);

In section 7.5.3.2, we change:

• Otherwise, if M_P has more specific parameter types than M_Q, then M_P is better than M_Q. Let { R₁, R₂, …, R_N } and { S₁, S₂, …, S_N } represent the uninstantiated and unexpanded parameter types of M_P and M_Q. M_P’s parameter types are more specific than M_Q’s if, for each parameter, R_X is not less specific than S_X, and, for at least one parameter, R_X is more specific than S_X:
  • A type parameter is less specific than a non-type parameter.
  • Recursively, a constructed type is more specific than another constructed type (with the same number of type arguments) if at least one type argument is more specific and no type argument is less specific than the corresponding type argument in the other.
  • An array type is more specific than another array type (with the same number of dimensions) if the element type of the first is more specific than the element type of the second.

to

• Otherwise, if M_P has more specific parameters than M_Q, then M_P is better than M_Q. Let { R₁, R₂, …, R_N } and { S₁, S₂, …, S_N } represent the parameters of M_P and M_Q, and let the parameter type represent uninstantiated and unexpanded parameter type. M_P’s parameters are more specific than M_Q’s if each R_X is not less specific than S_X, and at least one R_X is more specific than S_X:
  • For parameter type, a type parameter is less specific than a non-type parameter.
  • For parameter type, recursively, a constructed type is more specific than another constructed type (with the same number of type arguments) if at least one type argument is more specific and no type argument is less specific than the corresponding type argument in the other.
  • For parameter type, an array type is more specific than another array type (with the same number of dimensions) if the element type of the first is more specific than the element type of the second.
  • For parameter definition, a parameter annotated with BetterOverloadAttribute is more specific than a parameter not annotated with BetterOverloadAttribute.

---

@gafter commented on Mon Oct 05 2015

@ashmind In both options, you are adding a new bullet under the paragraph

In case the parameter type sequences {P1, P2, …, PN} and {Q1, Q2, …, QN} are equivalent (i.e. each Pi has an identity conversion to the corresponding Qi), the following tie-breaking rules are applied, in order, to determine the better function member.

Since P1 is IDictionary and Q1 is IReadOnlyDictionary, the sequences are not equivalent. Therefore neither change would help in the use case that motivated the proposal.

You've also messed up the intended meaning of this section, which was to provide a tie breaker when two identical method signatures are only identical because of instantiation and expansion of the method and enclosing types. None of that applies in your use case.

---

@ashmind commented on Mon Oct 05 2015

@gafter Hmm, you are right about the equivalence part.

I'm not sure about intended meaning of the whole section though -- seems like section overall defines which function is better for two applicable functions (applicable as per 7.5.3.1). What do you mean by "identical" in that case?

Based on the above, does the following make sense?

Member-level

At the very end of 7.5.3.2, add the following:
If none of the preceding rules identifies M_P as better than M_Q, and M_P is annotated with BetterOverloadAttribute, and M_Q is not annotated with BetterOverloadAttribute, then M_P is better than M_Q.

(That does not go as a list item to the "identity conversion" list, just below it)

---

@ashmind commented on Mon Oct 05 2015

Parameter-level (alternative)

Replace

Given an argument list A with a set of argument expressions { E₁, E₂, ..., E_N } and two applicable function members M_P and M_Q with parameter types { P₁, P₂, ..., P_N } and { Q₁, Q₂, ..., Q_N }, M_P is defined to be a better function member than M_Q if

• for each argument, the implicit conversion from E_X to Q_X is not better than the implicit conversion from E_X to P_X, and
• for at least one argument, the conversion from E_X to P_X is better than the conversion from E_X to Q_X.

With

Given an argument list A with a set of argument expressions { E₁, E₂, ..., E_N } and two applicable function members M_P and M_Q with parameters { P₁, P₂, ..., P_N } and { Q₁, Q₂, ..., Q_N }, M_P is defined to be a better function member than M_Q if

• for each argument, the implicit conversion from E_X to type of Q_X is not better than the implicit conversion from E_X to type of P_X, and
• for at least one argument, one the following applies:
  • the conversion from E_X to type of P_X is better than the conversion from E_X to type of Q_X
  • or, P_X is annotated with BetterOverloadAttribute and Q_X is not annotated with BetterOverloadAttribute.

---

@gafter commented on Mon Oct 05 2015

@ashmind Re "I'm not sure about intended meaning of the whole section though"

That section is for when two overloads that were originally different collide (become identical) because of generic instantiation and/or params expansion.

---

@ashmind commented on Mon Oct 05 2015

@gafter OK I see the confusion, I just understood your "section" term as referring to the whole of 7.5.3.2 and so was confused as it's not just about identical overloads. Now I see it, thanks.

Anyway, does my new spec make sense?

---

@jnm2 commented on Mon Nov 21 2016

I want this so bad. I have the exact same IReadOnlyDictionary vs IDictionary extension method pain.

Is it possible to need a tiebreaker between three overloads but at the same time need another tiebreaker between just two of them for a different call site? If so we'll need a priority parameter. (yuck)

---

@ashmind commented on Mon Apr 10 2017

@gafter Is there an automatic way to migrate this to dotnet/csharplang?

---

@jnm2 commented on Tue Oct 03 2017

@ashmind Anyone can migrate this with ZenHub or a similar tool. Do you want to, or shall I?

[Thaina]

Was having this problem making stackoverflow exception because it calling recursively when I expect it to call underlying function