Generic constraints should prune out candidates for method group natural type #69222
Labels
Area-Compilers
Area-Language Design
Bug
New Feature - Lambda Improvements
Resolution-Duplicate
The described behavior is tracked in another issue
Milestone
I wrote this into a speclet.
The following should not have an error:
Neither should this scenario:
We should probably also tweak the arity check so that the following can succeed. We could instead check that no type parameter was left unsubstituted.
That means this scenario would start working:
Also, should the signature matching check be performed after type argument substitution?
In the case where the method group is specified with no type arguments, we'll have no mechanism to infer any type parameters on candidate methods, so generic candidates should be removed.
We may also consider tweaking the notion of "unique signature", as the following scenario currently fails to determine a natural type:
Follow-up on dotnet/csharplang#7380 (change to look scope-by-scope when determining the natural type of a method group)
The text was updated successfully, but these errors were encountered: