Skip to content
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

Generic constraints should prune out candidates for method group natural type #69222

Closed
jcouv opened this issue Jul 25, 2023 · 1 comment
Closed
Assignees
Milestone

Comments

@jcouv
Copy link
Member

jcouv commented Jul 25, 2023

I wrote this into a speclet.

The following should not have an error:

var x = new C().M<int>; // CS8917	The delegate type could not be inferred.

public class C
{
    public void M<T>() { }
    public void M<T>(object o) where T : class { }
}

Neither should this scenario:

System.Action x = new object().M; // okay
var y = new object().M; // CS8917	The delegate type could not be inferred.

static class E1
{
    public static void M<T>(this T t) { }
}

static class E2
{
    public static void M<T>(this T t) where T : struct { }
}

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.

var d = new C().M; // CS8917	The delegate type could not be inferred.

static class E
{
    public static void M<T>(this T t) { }
}

That means this scenario would start working:

using N;

var d = new C().M;
d();

class C { }

static class E1
{
    public static void M<T>(this C c) { } // this extension method would be skipped
}

namespace N
{
    static class E2
    {
        public static void M(this C c) { } // this outer extension method would be picked
    }
}

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.

var x = new C().M;

public class C
{
    public void M() { }
    public void M<T>(T t) { } // this overload has no chance of winning (it would fail even if it were the only overload) so should be pruned early
}

We may also consider tweaking the notion of "unique signature", as the following scenario currently fails to determine a natural type:

var x = new object().F;

static class B
{
    internal static void F<T>(this T x) { }
}

static class A
{
    internal static void F(this object x) { }
}

Follow-up on dotnet/csharplang#7380 (change to look scope-by-scope when determining the natural type of a method group)

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead labels Jul 25, 2023
@jcouv jcouv self-assigned this Jul 25, 2023
@jcouv jcouv added this to the 17.8 milestone Jul 25, 2023
@jcouv jcouv added Bug Area-Language Design and removed untriaged Issues and PRs which have not yet been triaged by a lead labels Jul 25, 2023
@jcouv jcouv modified the milestones: 17.8, 17.9 Aug 8, 2023
@jcouv
Copy link
Member Author

jcouv commented Aug 18, 2023

Closing as subsumed by #69432 (test plan for changes to method group natural type in C# 13).

@jcouv jcouv closed this as not planned Won't fix, can't repro, duplicate, stale Aug 18, 2023
@jcouv jcouv added the Resolution-Duplicate The described behavior is tracked in another issue label Aug 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant