Lambdas omitting parameters about roslyn

[HaloFour]

A wildcard character had been described in the C# Pattern Matching proposal which may be up for further discussion for C# 7.0. That character was * which does make more sense as _ is considered a valid C# identifier.

How about also allowing skipping multiple arguments?

void Foo(Func<string, int, bool, DateTime, decimal> func) { ... }

Foo(delegate { return 0m; }) // already valid C# 2.0+
Foo((*) => 0m); // shorthand for above
Foo((s, i, *) => 0m); // capture first two args, skip the rest

If there are overloads which accept Func<>s of differing numbers of arguments the overload resolution would select the one with the fewest remaining parameters:

void Foo(Func<string, int, bool, DateTime, decimal> func) { ... }
void Foo(Func<string, int, bool, byte, DateTime, decimal> func) { ... }

Foo((s, i, *) => 0m); // calls the first Foo
Foo((s, i, *, *, *) => 0m); // calls the second Foo

The one issue here, which also affects normal lambdas, is if there are overloads which accept a delegate with the same number of arguments but only differ by the type of those arguments. The only solution that I can think of there is to require specifying the type of the parameter in the lambda, but that makes the entire concept of catching multiple arguments feel weird.

void Foo(Func<string, int, bool> func) { ... }
void Foo(Func<string, string, bool> func) { ... }
void Foo(Func<string, string, int, bool> func) { ... }

Foo((s, int *) => true); // calls first Foo
Foo((s, string *) => true); // calls second Foo
Foo((s, string *, *) => true); // calls third Foo, but ewww

I think that a wildcard would be useful in a number of other scenarios as well, like the following:

string s = ...;
if (int.TryParse(s, out *)) {
    // Don't need the parsed value, no need to declare an extra variable
}

[MadsTorgersen]

This should be thought of as a special case of allowing deconstruction in parameter position, which is something we will consider down the line.

[Khazuar]

The choice of the wildcard-symbol is not that important. I agree that _ may be a poor choice because it breaks backwards-compatibility and I like * just as much.
Pattern-matching might be an interesting feature, but I think this here might be something independent. It's nonetheless a good idea though to keep the wildcard-symbol consistent.
I like the idea of having a way to also skip all following arguments, although I am not sure this increases readability in the end. An explicit symbol might be useful, so a reader knows there is some magic happening:

void Foo(Func<string> func) { ... }
void Foo(Func<int, int, string> func) { ... }
void Foo(Func<int, int, bool, DateTime, string> func) { ... }

Foo(() => "0"); //->Calls first function
Foo(* => "0"); //->Compiler error, no function with 1 argument available
Foo((*) => "0"); //->Compiler error, no function with 1 argument available

Foo(** => "0"); //->Calls second function
Foo((**) => "0"); //->Calls second function
Foo((i, *) => i.ToString()); //->Calls second function
Foo((*, n) => n.ToString()); //->Calls second function
Foo((i, **) => i.ToString()); //->Calls second function

Foo((i, *, *) => i.ToString()); //->Compiler error, no function with 3 arguments available
Foo((i, *, **) => i.ToString()); //->Calls third function
Foo((i, *, *, *) => i.ToString()); //->Calls third function
Foo((i, *, *, **) => i.ToString()); //->Calls third function

Foo((i, *, *, *, *) => i.ToString()); //->Compiler error, no function with 5 arguments available
Foo((i, *, *, *, **) => i.ToString()); //->Compiler error, no function with 5+ arguments available

The ** can therefore be used to skip all following (at least 1) parameters, choosing the function with the fewest arguments available. ** can only be used as the last argument of the lambda.

I actually have no problem with typing the wildcards. Of course the ** can not be typed, but single-wildcards should not be a problem. This also avoids the ugly example of @HaloFour to be that ugly.

[wcabus]

I attended a talk about C# 7 yesterday and saw the tuples and deconstruction features introducing the * wildcard to deconstruct a tuple where you only need certain values and lose the rest. This gave me the idea that it would be nice to also have a * wildcard for expressions, i.e. when dealing with events:

public event EventHandler SomethingChanged;

private void DoStuff() {
    SomethingChanged += (*, *) => { 
        // No need for sender and EventArgs 
    };
}

[gafter]

We are now taking language feature discussion on https://github.com/dotnet/csharplang for C# specific issues, https://github.com/dotnet/vblang for VB-specific features, and https://github.com/dotnet/csharplang for features that affect both languages.

This proposal corresponds to dotnet/csharplang#111