More concise lambdas that accept parameters by reference

[teo-tsirpanis]

Consider the following piece of code:

readonly struct MyStruct {
    // ...
}

delegate void MyDelegate(in MyStruct s, int i);

void MyMethod(MyDelegate del) {
    // ...
}

It declares a read-only struct, a delegate that accepts a read-only reference of it, and a method that accepts this delegate. Such constructs are becoming more and more common in high-performance code that avoids needless data copyings.

Before we continue, let's imagine how the code above would be used if MyStruct was passed to MyDelegate by value:

delegate void MeDelegate(MyStruct s, int i);

void MyMethod(MyDelegate del) {
    // ...
}

// We use both s and i.
MyMethod((s, i) => Console.WriteLine($"s: {s}, i: {i}"));
// We use only i.
MyMethod((_, i) => Console.WriteLine(i));

Everything is clean and simple, but not anymore. Because as soon as we pass MyStruct by reference, the compiler does not allow defining the delegates the same way. It now needs the in keyword for the first parameter definition, which in turn needs the type name of MyStruct to be spelt, which in turn needs the type name of all other parameters' (namely i's) type names to be spelt as well, resulting in the following more verbose snippet:

MyMethod((in MyStruct s, int i) => Console.WriteLine($"s: {s}, i: {i}"));

And God forbid if the types were longer (typing in ReadOnlySequence<byte> x for example would be 27 characters long), or there were more parameters.

The proposal

I propose to relax the compiler's rules and accept lambdas like the following:

// We use both s and i.
MyMethod((in s, i) => Console.WriteLine($"s: {s}, i: {i}"));
// We use only i.
MyMethod((_, i) => Console.WriteLine(i));

On the first example, s which is passed as a read-only reference, only needs the in keyword in front of it. The declaration of i which is passed by value, does not change in any way.

The second example takes it a bit further and does not require us to use the in keyword for parameters we discard, making it identical to the snippet shown earlier where MyStruct is passed by value.

More details

• Of course the proposal also applies to lambdas that use ref and out in their parameters. When I mention in, I also mean ref and out.

• I consider the presence of the in keyword important; the proposal does not move to allow completely removing it and identically defining the lambda as if the parameter was passed by value, but feel free to override me if you see fit.

• What if the parameter we named _ is passed by reference and is actually used? Assuming that the in keyword becomes required, we could allow this:

MyMethod((in _, i) => Console.WriteLine(_));

but not this:

MyMethod((_, i) => Console.WriteLine(_));

Of course we would not allow using _ at all if more than one parameters were discarded, regardless of any keyword in front of them.

• F# already supports this feature. The following snippet is equivalent to the C# one:

[<Struct>] type MyStruct = MyStruct

type MyDelegate = delegate of s: inref<MyStruct> * i: int -> unit

let myFunction (d: MyDelegate) = ()

// We use both s and i.
myFunction (MyDelegate(fun s i -> printfn "S: %A, i: %d" s i))
// We use only i.
myFunction (MyDelegate(fun _ i -> printfn "%d" i))
// And we didn't use any type annotations inside the lambda!

[CyrusNajmabadi]

Dupe of #338, which i am championing.

[ronnygunawan]

I believe this is included in the proposed Lambda improvements

lambda_expression
  : modifier* identifier '=>' (block | expression)
  | attribute_list* modifier* type? lambda_parameters '=>' (block | expression)
  ;

[333fred]

No, it is not.