Proposal: Extension Methods on Method Groups #5482
Replies: 13 comments
-
Related: dotnet/roslyn#3990 |
Beta Was this translation helpful? Give feedback.
-
@sharwell Oops; fixed |
Beta Was this translation helpful? Give feedback.
-
@alrz yes dotnet/roslyn#3990 would benefit from this, but this proposal stands on its own. |
Beta Was this translation helpful? Give feedback.
-
@aluanhaddad Yes, but that particular example that I mentioned requires the lambda to have a default type. |
Beta Was this translation helpful? Give feedback.
-
@alrz I see what you mean. Because the conversion target would need to be manifest for method selection to even occur. In the black magic case (which all is in my head and I may well be insane), we are essentially saying: |
Beta Was this translation helpful? Give feedback.
-
I think that's a better idea because the compiler cannot know about all possible delegate types (unless dotnet/roslyn#3990 looks up for other delegate types in scope if Action and Func were not applicable which is unlikely). |
Beta Was this translation helpful? Give feedback.
-
If I understand correctly, the proposal is to add the bold text below to the spec section 7.6.6.2:
|
Beta Was this translation helpful? Give feedback.
-
@SLaks Thanks, edited. |
Beta Was this translation helpful? Give feedback.
-
Yes; that's exactly what I mean. It would make scanning for extension methods a bit more costly (since it has to consider more conversions); I don't know how bad that is. |
Beta Was this translation helpful? Give feedback.
-
This would be beautiful, and would make the language more functional. The Is it being considered for v8? |
Beta Was this translation helpful? Give feedback.
-
@giggio It is not. |
Beta Was this translation helpful? Give feedback.
-
Here is a use case for this, driven by #424 public static TResult Splat<T1, T2, T3, TResult>(this Func<T1, T2, T3, TResult> method, (T1, T2, T3) args)
{
return method(args.Item1, args.Item2, args.Item3);
}
void example()
{
var input = (1d, 1d, 1d);
(double, double) output;
// These both work:
output = Extensions.Splat(Globe.ConvertToSpherical, input);
output = ((Func<double, double, double, (double, double)>)Globe.ConvertToSpherical).Splat(input);
// This doesn't compile. Error:
// CS0119 'Globe.ConvertToSpherical(double, double, double)' is a method, which is not valid in the given context
output = Globe.ConvertToSpherical.Splat(input);
}
(double theta, double psi) ConvertToSpherical(double x, double y, double z)
{
throw new NotImplementedException();
} |
Beta Was this translation helpful? Give feedback.
-
It would also be nice if we could do the following (automatically find the best matching type (action) for method groups): value switch
{
value => value.SomeMethod,
}();
// or, if there is no native suport for this, we could at least define a method like this:
private Action AsAction(Action action)
=> action;
// and then do this:
value switch
{
value => value.SomeMethod.AsAction(),
}(); Because at the moment, if I have a task, I can use expression switches for "void like" meaning the void task returning nothing when awaited and have the await before the expression. There's no reason for that limitation with void - just accepting void as a return type for an expression switch would be nice too, but I guess that's not realistic from what I've read in other issues. Void-Task example that compiles (showing that in theory, void expressions would make just as much sense): private Task Run(int value) => Task.CompletedTask;
private Task Run2() => Task.CompletedTask;
await (value switch
{
3 => Run(value),
_ => Run2(),
}); But this does not work: private void Run(int value) => NoOperation();
private void Run2() => NoOperation();
// Doesn't work (statement not allowed there)
value switch
{
3 => Run(value),
_ => Run2(),
};
// Doesn't work (void can not be assigned to variable)
_ = value switch
{
3 => Run(value),
_ => Run2(),
};
// Doesn't work (no best type found)
value switch
{
3 => () => Run(value),
_ => Run2,
}();
// Does work, but is really annoying and adds noise for no reason, and you can't use expression bodies anymore if you're writing a method
Action runner = value switch
{
3 => () => Run(value),
_ => Run2,
};
runner(); Allowing Extension methods on Method groups would give some flexibility, and automatically detecting that Action is the best type here (not only when running Extension methods like the proposal) would be an even bigger improvement over status quo. Are there any updates wheter this is considered as a champion for v11 or v12? |
Beta Was this translation helpful? Give feedback.
-
Can you please allow extension methods to be called on method groups or lambdas via method group conversion to a delegate or expression type?
You should then also allow deconstructing assignments of method groups & especially lambdas (via
public static void Deconstruct(this Expression<Func<...>>, out ...)
).Benefits
This would allow a number of useful extension methods, such as
Risks
Very little; none of this is currently valid syntax, so this should not be a breaking change.
This would remove the following errors:
This could be a bit confusing if a method group and extension method have multiple matching overloads, but that issue already exists when calling non-extension methods.
Implementation
All of these examples are already callable without extension syntax, using delegate conversions on the first parameter. Just allow these conversions when selecting extension methods too.
Beta Was this translation helpful? Give feedback.
All reactions