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

Type arguments are not being inferred correctly from method group #73347

Closed
hez2010 opened this issue May 6, 2024 · 2 comments
Closed

Type arguments are not being inferred correctly from method group #73347

hez2010 opened this issue May 6, 2024 · 2 comments
Labels
Area-Compilers Area-Language Design Resolution-By Design The behavior reported in the issue matches the current design untriaged Issues and PRs which have not yet been triaged by a lead

Comments

@hez2010
Copy link

hez2010 commented May 6, 2024

Version Used: .NET 8

Steps to Reproduce:

var foo = new Foo();
Bar(foo.A<int, int, int, int>); // <--- error
Bar(ReturnMySelf(foo.A<int, int, int, int>)); // <--- ok

void Bar<T1, T2, T3, TResult>(Func<T1, T2, T3, TResult> func) {}
T ReturnMySelf<T>(T x) => x;

class Foo { public extern TResult A<T1, T2, T3, TResult>(T1 a, T2 b, T3 c); }

It's too weird that you just return the type itself and then it gets inferred.

Expected Behavior:

The compiler can infer the type arguments in both two Bar calls.

Actual Behavior:

Only the second call Bar(ReturnMySelf(foo.A<int, int, int, int>)) can infer the type arguments correctly.

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead labels May 6, 2024
@huoyaoyuan
Copy link
Member

I believe this is a language issue, natural type of method group doesn't employ such inference.

@jcouv
Copy link
Member

jcouv commented May 15, 2024

Yes, I think this is currently by-design. We have a csharplang proposal to make this work.
Note: the current workaround would be to use a lambda Bar((int x, int y, int z) => foo.A<int, int, int, int>(x, y, z));.

@jcouv jcouv added Resolution-By Design The behavior reported in the issue matches the current design Area-Language Design labels May 15, 2024
@jaredpar jaredpar closed this as not planned Won't fix, can't repro, duplicate, stale May 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers Area-Language Design Resolution-By Design The behavior reported in the issue matches the current design untriaged Issues and PRs which have not yet been triaged by a lead
Projects
None yet
Development

No branches or pull requests

4 participants