C# Lambda Parameters: Syntax, Types, and Common Pitfalls

When you write a lambda expression in C#, the parameter list defines the shape of the anonymous function you are creating. Understanding how c# lambda parameters work—what types you can declare, which modifiers are allowed, and how they interact with delegate types—prevents a range of compile-time and runtime surprises. This article covers the syntax, the rules, and the practical limitations you will encounter when working with lambda parameters in everyday code.

Lambda Parameter Syntax Basics

A lambda expression consists of a parameter list, the => operator, and an expression or statement block. The parameter list appears on the left side of the arrow. The simplest form has a single parameter without parentheses:

Func<int, int> square = x => x * x;

Here x is the parameter, and its type is inferred from the Func<int, int> delegate. When a lambda has multiple parameters, parentheses are required:

Func<int, int, int> add = (a, b) => a + b;

Zero parameters use empty parentheses:

Action sayHello = () => Console.WriteLine("Hello");

The parameter list in a lambda is not a method declaration; it is a shorthand that must match the delegate type you assign it to. This means the compiler checks parameter count, types, and modifiers against the delegate signature.

Explicit and Implicit Parameter Types

Lambda parameters can be implicitly typed, as shown above, or explicitly typed. Explicit typing is useful when the delegate type is not immediately obvious or when you want to make the parameter type clear to readers:

Func<int, int> square = (int x) => x * x;

You cannot use var for a lambda parameter. The compiler requires either an explicit type or enough context to infer the type from the delegate. Attempting to write (var x) => x * x produces a compile error because var is not allowed in a lambda parameter list.

Implicit typing works because the compiler infers the parameter type from the target delegate type. If the delegate type is not known, for example when a lambda is passed directly to a method with an object parameter, the compiler cannot infer the parameter types and you must specify them explicitly.

Using ref, out, and in Parameters

Lambda expressions support ref, out, and in parameter modifiers, provided the delegate type also uses those modifiers. For example, you can define a delegate that takes a ref parameter and assign a lambda to it:

delegate void RefAction(ref int value);

RefAction increment = (ref int n) => n++;

int number = 5;
increment(ref number);
Console.WriteLine(number); // 6

Similarly, out parameters work with lambdas, but you must assign a value to the parameter before the lambda returns, just as with regular methods:

delegate bool TryParseDelegate(string input, out int result);

TryParseDelegate parse = (string s, out int r) => int.TryParse(s, out r);

in parameters are read-only and can be used in lambdas as well:

delegate void ReadOnlyAction(in int value);

ReadOnlyAction print = (in int v) => Console.WriteLine(v);

One important limitation: async lambdas cannot have ref or out parameters. The compiler rejects such code because ref and out are not allowed in async methods, and the same rule applies to async lambdas. If you need to combine asynchronous work with ref or out, you must restructure your code, for example by returning a tuple or using a custom class.

Why params and Default Values Are Not Allowed

Lambda parameters cannot use the params keyword, and they cannot have default values. These restrictions exist because a lambda's signature is determined by the delegate type it is assigned to. The params modifier and default values are features of method declarations, not of anonymous function signatures.

If you try to write a lambda with a params array:

Func<int[], int> sum = (params int[] numbers) => numbers.Sum(); // Compile error

the compiler reports that params is not valid in this context. Similarly, default values like (int x = 5) => x are not allowed. To achieve similar behavior, you can use a delegate that accepts an array or a List<T> and handle the default logic inside the lambda body.

How Lambda Parameters Map to Delegate Types

The delegate type defines the contract for the lambda. For Func<T, TResult>, the last type parameter is the return type, and the preceding ones are the parameter types. For Action<T>, all type parameters are parameter types and the return type is void. When you assign a lambda to a delegate, the compiler checks that the parameter list matches exactly.

Consider these examples:

Func<int, string, bool> isValid = (age, name) => age > 18 && !string.IsNullOrEmpty(name);
Action<int, string> log = (id, message) => Console.WriteLine($"{id}: {message}");

In the first case, the lambda has two parameters: int and string, and returns bool. In the second, it has two parameters and returns void. The parameter types are inferred from the delegate type, but you can also specify them explicitly if you prefer.

A common mistake is to mismatch the number of parameters or their types. For example, assigning a lambda with three parameters to a Func<int, int> produces a compile error. The compiler will tell you the expected delegate signature, so the error message is usually clear.

Common Mistakes with Lambda Parameters

One frequent error is trying to use var for a lambda parameter, as mentioned earlier. Another is attempting to use params or default values, which are not supported. Developers also sometimes forget that ref and out must appear both in the delegate declaration and in the lambda parameter list. If the delegate uses ref but the lambda omits it, the code will not compile.

Another subtle issue is type inference when a lambda is used in a context where the target type is not a delegate. For example, passing a lambda to a method that expects object will fail because the compiler cannot infer the parameter types. In such cases, you must cast the lambda to a specific delegate type or specify the parameter types explicitly.

Finally, be careful with parameter names. Lambda parameter names are scoped to the lambda body and can shadow outer variables, but this can lead to confusing code if you are not intentional about naming. Using short, descriptive names like x, y, or item is common, but in complex lambdas, more descriptive names improve readability.

Allocation and Performance Considerations

Lambda parameters themselves do not introduce performance overhead; the cost comes from delegate allocation and closure captures. When a lambda captures variables from its enclosing scope, the compiler generates a closure object that holds those variables. This allocation happens each time the lambda is created, which can be significant in hot paths.

For example, consider a loop that creates a lambda with a captured parameter:

var list = Enumerable.Range(1, 1000);
int threshold = 5;
var filtered = list.Where(x => x > threshold);

The lambda captures threshold, so each iteration of the Where call uses the same closure instance. However, if you create the lambda inside a loop body, a new closure is allocated per iteration. To minimize allocations, you can hoist the lambda creation out of the loop or use a static lambda that does not capture variables.

The parameter list itself has no runtime cost; the delegate's Invoke method is called with the specified arguments. Using ref or out parameters can affect how arguments are passed, but the overhead is negligible compared to the delegate invocation itself. In performance-sensitive code, the main concern is avoiding unnecessary delegate allocations, not the parameter syntax.

If you need to pass many arguments, consider using a custom struct or a ValueTuple to reduce the number of parameters and improve readability. The delegate signature can then accept a single tuple parameter, which also makes it easier to change the parameter set without modifying every call site.

Understanding c# lambda parameters is not just about syntax; it is about knowing what the compiler enforces and how your choices affect the generated code. By following the rules for parameter types, modifiers, and delegate compatibility, you can write lambdas that are both concise and correct.