CARVIEW |
Navigation Menu
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Replies: 18 comments · 8 replies
-
Is this something that should be related to Bestest Betterness #98? |
Beta Was this translation helpful? Give feedback.
All reactions
-
It depends on the shape of the proposed solution/specification. Absent a proposed solution, I would say no. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 1 -
π 1
-
This is such an annoying feature of C#. Having it infer the type parameters when the method group only consists of one method would be a really useful addition to the language. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 7
-
This does seem like a major flaw that needs to be rectified, especially for those of us using first-class functions everywhere -- it's a real pain point. The fact that this invisible thing called a 'method group' (which no coder understands unless they know how the compiler works) gets in the way of treating methods as first-class functions is crazy. Even if there are multiple methods in the group. "Method group" shouldn't even be in a C# programmer's lexicon. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 17
-
I just got bitten by this. Thought I was being really clever and created a t4 template to generate helpers for partial function application only to find I couldn't pass "method groups" to them. https://gist.github.com/bradphelan/ca92cd8e8a7b619712799474a27f60e6 |
Beta Was this translation helpful? Give feedback.
All reactions
-
I hear people asking for a solution to this. Has anyone a proposed solution (i.e. a modification to the language specification) that is implementable? |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 1
-
How about the following as a starting point:
To:
To:
(my additions in italics). This seems trivially simple. So what have I missed? π |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 3
-
That doesn't quite work. The type of a method in a method group isn't known until after type inference (because it could be a generic method). |
Beta Was this translation helpful? Give feedback.
All reactions
-
Also, the number of methods in a method group isn't a defined concept. When there is no instance method but there is an extension method, what is the number of methods in the method group? |
Beta Was this translation helpful? Give feedback.
All reactions
-
Also, when there is exactly one method in the method group but with a |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 1
-
This keeps coming back. What's the smallest change we can make to the spec that would allow this to resolve? |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 5
-
I think the root of the problem is where for type inference on the method group, we need to know what the exact delegate type it is going to. We could infer |
Beta Was this translation helpful? Give feedback.
All reactions
-
As a proof of concept, here's the minimum changes for such program to successfully compile: |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 6 -
π 3
-
Would this help with this issue? If so, then this would be a really helpful improvement! |
Beta Was this translation helpful? Give feedback.
All reactions
-
I recently hit something similar to this but I'm not sure that would be the same issue as it won't work with a lambda expression either, interface I {
Task<object> MethodAsync(object x);
}
static class C {
static void Test()
{
Create((I v) => v.MethodAsync); // error
Create((I v) => x => v.MethodAsync(x)); // error
Create<object, object, I>(v => v.MethodAsync); // ok
}
static Func<T, U> Create<T, U, V>(Func<V, Func<T, Task<U>>> factory) => null;
} |
Beta Was this translation helpful? Give feedback.
All reactions
-
Is this change happening? There seems to be agreement that it would be a good thing to have. |
Beta Was this translation helpful? Give feedback.
All reactions
-
This isn't championed so isn't on the roadmap for now. That said, if you (or anyone else) wants to push this forward, opening an issue containing a formal proposal explaining exactly how the c# spec should change could definitely increase the likelihood of this happening. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 1
-
This is likely addressed by "lambda natural type" feature (@cston?) |
Beta Was this translation helpful? Give feedback.
All reactions
-
That's what I thought, too. C#10 is still not inferring the type though.
|
Beta Was this translation helpful? Give feedback.
All reactions
-
π 1
-
That's because you're converting it to
Did this ever get resolved? |
Beta Was this translation helpful? Give feedback.
All reactions
-
I drafted a spec change to solve this, along with various method group improvements. Here's the relevant part:
That is the mechanism that allowed explicitly-typed lambdas to contribute to type inference:
So this change should allow a method group with a unique signature to work:
|
Beta Was this translation helpful? Give feedback.
All reactions
-
π 6 -
β€οΈ 2
-
Would this affect type inference of type parameters on the method group itself? Sounds like there's something special about return-type that cause it to not being inferred where possible. (sharplab.io) using System;
TestNone(Both<int, bool>); // (1)
TestNone(In); // ok
TestNone(Out<bool>); // (2)
TestNone(None); // ok
//TestIn(Both);
//TestIn(In);
TestIn<int>(Out<bool>); // (3)
TestIn<int>(None); // proposed
//TestOut(Both);
TestOut(In); // ok
//TestOut(Out);
TestOut(None); // ok
//TestBoth(Both);
//TestBoth(In);
//TestBoth(Out);
TestBoth<int, bool>(None); // (4)
static R Both<T, R>(T arg) => throw null!;
static bool In<T> (T arg) => throw null!;
static T Out<T> (int arg) => throw null!;
static bool None (int arg) => throw null!;
static void TestNone (Func<int, bool> predicate) { }
static void TestIn<T> (Func<T, bool> predicate) { }
static void TestOut<T> (Func<int, T> predicate) { }
static void TestBoth<T, R>(Func<T, R> predicate) { } |
Beta Was this translation helpful? Give feedback.
All reactions
-
@alrz No, I don't think it would not affect the determination of the method group itself. I didn't understand the numbered comments "(n)" and the "proposed" line in the code sample. ( I need to look more at the interaction between conversion rules and inference rules. For example, could |
Beta Was this translation helpful? Give feedback.
All reactions
-
"proposed" is the example in OP, type args for the rest should be possible to infer when unspecified. Not sure if/how lambda return-types contribute to type inference, but if that's the case I guess that's also applicable to method groups. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 2
-
Will the proposal be delivered for .NET9? |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 1
-
Unlikely for .NET 9. We're heads down to deliver the features we're already working on (see feature status) already. |
Beta Was this translation helpful? Give feedback.
All reactions
-
π 2
This discussion was converted from issue #129 on September 08, 2020 19:37.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
@jnm2 commented on Mon Jan 30 2017
Please allow the following. I see no possible ambiguity in this scenario. The
IsEven
andTest
method groups have only one overload which fits the delegate signature.Expected Behavior:
Infers
Test<int>(IsEven)
and compilesActual Behavior:
CS0411 The type arguments for method 'Program.Test(Func<T, bool>)' cannot be inferred from the usage. Try specifying the type arguments explicitly.
@jaredpar commented on Mon Jan 30 2017
Believe this is by design but will let @gafter comment on exactly how.
@gafter commented on Mon Jan 30 2017
Type inference doesn't infer based on an argument that is a method group, no matter how many or few members the method group has. The conversion from a method group to a delegate (of some particular type) occurs after type inference has completed to determine what that delegate type is.
Having said that, I imagine it might be possible to modify (the specification for) type inference to get the behavior @jnm2 would like. Who would like to take a crack at it?
Beta Was this translation helpful? Give feedback.
All reactions