OverloadResolutionPriority with Deconstruct Extension Methods and Generics

[fitdev]

Not sure why CS is complaining about ambiguity in this case:

public readonly struct OneOf<T0, T1> {
  internal readonly T0? _value0;
  internal readonly T1? _value1;
}

public static class Extensions {
  //Open Generic deconstructor
  [OverloadResolutionPriority(-10)]
  public static void Deconstruct<T0, T1>(this OneOf<T0, T1> it, out T0? v0, out T1? v1) { v0 = it._value0; v1 = it._value1; }
}

public static class Extensions2 {
  //Closed Generic deconstructor
  [OverloadResolutionPriority(1)]
  public static void Deconstruct(this OneOf<int, char> v, out int i1, out char c2) {
    //...
  }
}

static class ConsumeAPI {
  static void Foo(OneOf<int, char> v) {
    var (i, c) = v; // <- CS0121: The call is ambiguous between the following methods or properties: 'Extensions.Deconstruct<T0, T1>(OneOf<T0, T1>, out T0?, out T1?)' and 'Extensions2.Deconstruct(OneOf<int, char>, out int, out char)'
  }
}

I would imagine that even without ORP attribute, the one with concrete types (closed generic - OneOf<int, char>) would be chosen. But here it is ambiguous even when ORP is applied in both places. Is this by design? Or is it a bug in Roslyn?

[333fred]

Is this by design?

Certainly, the ORPA behavior is by design. The spec explicitly says that ORPA is only considered within the containing type of the method, and that it cannot be used for conflicting extension method disambiguation when those extensions are defined in different types.

As to the overall question, I'm not entirely certain that deconstruction uses overload resolution by the same rules as standard method overload resolution, but I'd need to read through the spec and play with the code a bit to answer whether this is a bug. Perhaps @jcouv has some insight?

[fitdev]

Certainly, the ORPA behavior is by design. The spec explicitly says that ORPA is only considered within the containing type of the method, and that it cannot be used for conflicting extension method disambiguation when those extensions are defined in different types.

Thank you for pointing this out. Are there any plans to extend the scope of ORPA or come up with another attribute for specifically the purpose of being able to target extensions in different types?

[333fred]

Are there any plans to extend the scope of ORPA or come up with another attribute for specifically the purpose of being able to target extensions in different types?

No. We considered this, but ultimately we decided we don't want to get involved in an arms race between API authors trying to decide "mine is better than yours". ORPA is a tool for an author to influence which overloads of theirs are better.

[colejohnson66]

Has there been consideration to extending it to consider the entire assembly equally? I can understand the concern about "an arms race", but if it's in the same assembly, you'd be opting into said behavior yourself.

[bzd3y]

This works for me in VS 2022 17.13.6 as well as in Sharplab.io. So I think there might be something else going on.

Ah, I figured it out. If you make the out parameters for Extensions2.Deconstruct nullable like they are for Extensions1 then it does complain.

But then if you make the type parameters for the OneOf<> passed into Foo nullable then it will work again (without the OverloadResolutionPriority).

Also, if you make everything, including the fields in OneOf<>, non-nullable, then it also seems to work fine.

If you need that mixing of nullable and non-nullable then it's probably worth rethinking what you are doing. I would think that would cause a lot of problems.

[bzd3y]

Yeah, it could be something with that. But I don't think they would deliberately introduce a breaking change like that. So you might want to file an issue in the Roslyn repository.

[jcouv]

Verified this is now working in roslyn main branch. PR adds additional testing

[fitdev]

So the issue then is with an older version of Roslyn (4.14.0-3.25202.5 (f76d6ab7)), and it is allowed by the language?

[jcouv]

To be specific, I verified in main branch that ORPA works as expected with extension Deconstruct methods, and also that generic Deconstruct methods work as expected.
I also manually tested your code above in a recent VS preview (using compiler version: '4.14.0-3.25227.1 (49152f06)') and got not compilation error.