Champion "Lambda discard parameters" (VS 16.8, .NET 5)

[gafter]

Examples: (_, _) => 1, (int _, string _) => 1, void local(int _, int _) ...

• Proposal added (https://github.com/dotnet/csharplang/blob/master/proposals/csharp-9.0/lambda-discard-parameters.md)
• Discussed in LDM
• Decision in LDM
• Finalized (done, rejected, inactive)
• Spec'ed

See

• Permit discards in lambda parameters roslyn#16255
• LDM 2019/10/28 (restrict feature to lambdas and anonymous methods)

[DavidArno]

Please, please, please could this apply to methods too? Sometimes, the parameters must be there, but just aren't used. By way of example, this Unit type has to have both R# and CA1801 suppressions for the operator overloads:

public static bool operator ==(Unit u1, Unit u2) => true;
public static bool operator !=(Unit u1, Unit u2) => false;

Being able to write those with discards to reassure those checks that the parameters must be there, but aren't used, would clean up such code nicely:

public static bool operator ==(Unit _, Unit _) => true;
public static bool operator !=(Unit _, Unit _) => false;

[jnm2]

@DavidArno I believe the .NET Framework design guidelines have always been to use the names left and right specifically. https://msdn.microsoft.com/en-us/library/ms229004.aspx

[DavidArno]

@jnm2,

Oh, I didn't know that. I'll give that a try to see if it makes the compiler happier. Would still like to be able to use discards though.

[acple]

this proposal also permit in nested lambda expression _ => _ => true ?

Enumerable.Range(0, 3)
    .SelectMany(_ => Enumerable.Range(0, 3)
        .SelectMany(_ => Enumerable.Range(0, 3))); // i don't need parameters in nested

[gafter]

@acple Possibly not, unless we also do something like dotnet/roslyn#15793 at the same time.

[acple]

@gafter Thank you. in my opinion, lambda parameter shadowing is a bit dangerous but, discarded parameters are safe to overcover. so that should support only with discarded parameters. is this shadowing issue? or discarding issue?

[gafter]

@acple This is a shadowing issue. When there is only one lambda parameter named _, it is a normal identifier that declares a parameter. It must be so for backward compatibility.

[acple]

@gafter okay I understand. desire the identifier definition rules will be relaxed partially... thanks for the information! 😄

[MovGP0]

there should also be a compiler warning/error when using an _ named variable:

items.ForEach(_ => Console.WriteLine(_));

[DavidArno]

@MovGP0,

Unfortunately, that would be a breaking change. An analyzer could be added to this affect though.