Roslyn: Permit discards in lambda parameters

[gafter]

Please permit a lambda to have multiple declarations of parameters named _. In this case the parameters are "discards" and are not usable inside the lambda.

Func<int, int, int> zero = (_, _) => 0;

[Unknown6656]

I know, that people are going to kill me for saying this, but if I have an older C#-project, in which one lambda has the parameter called _, the program will not break with this feature, will it?

_<insert worried facial expression>_

[andrewjsaid]

I think @gafter means that the '_' parameters are discarded only in the case when there are more than one of them, which is not currently legal in C#. This makes the feature backwards compatible.

[jnm2]

@Unknown6656 That's what I read it to mean. "In this case [the case where there are multiple declarations of parameters named _] the parameters are "discards" and are not usable inside the lambda." Think it's unambiguous.

[bondsbw]

This appears to be a duplicate of #15027, and (as pointed out there by @HaloFour) it seems to be covered in #14794.

Is there any difference by using the term "discard" vs. "wildcard"?

[gafter]

We've dropped the term "wildcard" in preference of "discard". "Wildcard" implies regular expressions and some kind of matching, which don't have anything to do with discards. Discards are all about throwing something away. Anyway, they're both cards.

[gafter]

@bondsbw #14794 is an umbrella issue. This is broken out for tracking, since it isn't all being done at the same time.

[jjvanzon]

Any problem with leaving out the discard symbol altogether? For example:
(,) =>
MyMethod(=> Something());
(,x) =>
I guess the you cannot disambiguate between no parameter and one parameter. But would it matter? You're discarding them anyway.

[HaloFour]

@janjoostvanzon

Any problem with leaving out the discard symbol altogether?

Is a single character too verbose?

I guess the you cannot disambiguate between no parameter and one parameter. But would it matter? You're discarding them anyway.

It would for overload resolution. There could be two MyMethod methods, one could accept Action<T> and the other could accept Action<T1, T2>.

[jjvanzon]

@HaloFour:
About the overload resolution, I agree: it is a problem. Thanks for pointing it out. But aren't there a lot of cases where ambiguity in the C# language results in a compiler error and demands the use of a longer form? I think that 'no character' might just be unambiguous in 99% of the cases.

I don't feel very strongly about my suggestion, but I do like how 'no character' looks better than the underscore. But 'I just like it better' does make a very strong argument.

However, I could argue that no character is more concise than one character. Concise is one of the things I like about the C# language. I think it makes the language more readable. I think no character, nothing, expresses 'do nothing' better than anything. I feel it is a cleaner look.

I like this:

(int x,,) = GetTuple();

Better than this:

(int x, _, _ ) = GetTuple();

Thanks for the feedback.

[HaloFour]

@janjoostvanzon

Shrug, thinking of LINQ most of the extension methods do have overloads, one for just the element and another for the element and the index. So the issue would be pretty common there.

And no character is less than one character, but it's still a very minor difference. The use of _ allowed the parser to keep to the existing identifier parsing rules. Eliminating all of that would involve considerably more changes to the parser. I wouldn't be surprised if there are other scenarios where ambiguity would arise.

[gafter]

This has been moved to https://github.com/dotnet/csharplang/issues/111