-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Proposal] Improve overload resolution for delegate compatibility #3277
Labels
Needs Implementation
The specification for this issue has been approved, it needs an implementation
Proposal champion
Proposal
Milestone
Comments
Speaking of overload resolution, any chance #129 could be considered too? Though it's more about type inference, I'd say it is aligned with the motivation stated here. |
333fred
added a commit
to 333fred/csharplang
that referenced
this issue
Mar 19, 2020
This fixes a very similar problem to dotnet#3277, where this code is unable to be resolved: ```cs interface I1{} interface I2{} public unsafe class C : I1, I2 { void M(I1 i) {} static void M(I2 i) {} public void M1() { delegate*<C, void> a = M; // Ambiguous because both M's are applicable } } ``` With this change, the instance method M is not applicable, so there is no ambiguity.
333fred
added a commit
that referenced
this issue
Mar 19, 2020
* Only allow static methods for applicable members This fixes a very similar problem to #3277, where this code is unable to be resolved: ```cs interface I1{} interface I2{} public unsafe class C : I1, I2 { void M(I1 i) {} static void M(I2 i) {} public void M1() { delegate*<C, void> a = M; // Ambiguous because both M's are applicable } } ``` With this change, the instance method M is not applicable, so there is no ambiguity.
Maybe related: #4303 |
No, I don't believe that's related. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Needs Implementation
The specification for this issue has been approved, it needs an implementation
Proposal champion
Proposal
Improve overload resolution for delegate compatibility
Summary
Improve overload resolution when looking for applicable methods by removing methods that cannot be compatible. This will allow the following code to compile (it does not today):
Motivation
In the spirit of the other overload resolution changes we've made recently, removing things that already don't work, this would allow currently ambiguous code to compile and improve user experience.
Detailed design
Given the example in the Summary section, the reason why it does not compile today is straightforward, if requiring an intimate knowledge of the spec to figure out:
D
. To do that, we start by computing the applicable function members in the method groupD
.D
if the method inD
is applicable.D(MyAction<int>)
, we need to determine if the method groupY
is applicable toMyAction<T>
whereT
isint
.Y
.Y
, which is of typelong
. There is an implicit numeric conversion fromint
tolong
. There are no more parameters, soY
is applicable toMyAction<int>
and a method group conversion exists.Y
is not compatible withMyAction<int>
, it is applicable.D(MyAction<int>)
is an applicable member.D(MyAction<long>)
. The same sub-steps run again, andD(MyAction<long>)
is determined to be applicable.All of this occurs despite the fact that we can unambiguously determine that
D(MyAction<int>)
can never be a valid target forD(Y)
:Y
isn't compatible withMyAction<int>
. This is because the applicable function member algorithm looks for any implicit conversion for parameter types, and delegate compatibility looks only for implicit reference conversions. The proposed change, then, is to the first step of the method group conversions section of the spec (addition is italicized):Drawbacks
Any change is work.
Alternatives
Doing nothing.
Unresolved questions
N/A
Design meetings
The text was updated successfully, but these errors were encountered: