C# Statement Lambda: Syntax and Practical Usage

c# statement lambda requires a clear understanding of the core syntax, runtime behavior, and practical implementation patterns demonstrated in the examples below.

A statement lambda in C# is a lambda expression that uses a block body. Unlike an expression lambda, which evaluates to a single expression, a statement lambda can contain multiple statements, making it suitable for more complex logic that cannot be expressed as a single expression. The syntax is simple: parameters, the => operator, and a block enclosed in braces.

// Expression lambda
Func<int, int> square = x => x * x;

// Statement lambda
Func<int, int> squareWithLog = x =>
{
    Console.WriteLine($"Squaring {x}");
    return x * x;
};

The statement lambda above does two things: it writes a message and returns the square. This is the core difference: the block body allows arbitrary statements, but it also requires an explicit return statement when the delegate expects a return value.

Statement Lambda Syntax and Structure

The grammar for a statement lambda is straightforward:

(parameters) => {
    // statements
    // optional return
}

The parameter list follows the same rules as expression lambdas. You can omit parentheses for a single parameter, but if you use a block body, you still need to include the braces. The block can contain any valid C# statements: variable declarations, if blocks, for loops, try-catch blocks, and so on.

Here is a more involved example that uses a statement lambda to process a list:

List<int> numbers = new List<int> { 1, 2, 3, 4, 5 };
var evens = numbers.Where(n =>
{
    bool isEven = n % 2 == 0;
    if (isEven)
    {
        Console.WriteLine($"{n} is even");
    }
    return isEven;
}).ToList();

This lambda does more than filter; it also logs each even number. The Where method expects a Func<int, bool>, and the statement lambda provides that by returning a boolean.

When to Use a Statement Lambda vs an Expression Lambda

The choice between a statement lambda and an expression lambda is often about readability and complexity. An expression lambda is more concise and is required when you want to build an expression tree, such as in LINQ to Entities. Statement lambdas cannot be converted to expression trees, so they are not usable in scenarios that require an Expression<TDelegate>. For example, IQueryable methods like Where on DbSet<T> in Entity Framework accept an Expression<Func<T, bool>>, and passing a statement lambda will cause a compile-time error.

Use a statement lambda when:

• The logic requires more than a single expression, such as multiple statements or a switch statement.
• You need to declare intermediate variables to make the code clearer.
• You are working with delegates like Func or Action that do not require expression trees.

Use an expression lambda when:

• The body is a simple expression that can be written in one line.
• You need to pass the lambda to a method that expects an expression tree, like most LINQ-to-SQL or Entity Framework queries.
• You want to keep the code as short as possible.

The rule of thumb is: if you can write it as an expression lambda, prefer it. If you need more than one statement, switch to a statement lambda.

The following table summarizes the key differences:

Practical Examples: Statement Lambdas with Delegates and LINQ

Statement lambdas are commonly used with delegates like Func and Action. They are also useful in event handlers and asynchronous code.

Using Statement Lambdas with Func and Action

Func delegates return a value, while Action delegates return void. A statement lambda can be assigned to either.

Func<int, int, int> add = (a, b) =>
{
    int sum = a + b;
    Console.WriteLine($"Adding {a} and {b}");
    return sum;
};

Action<string> greet = name =>
{
    string message = $"Hello, {name}!";
    Console.WriteLine(message);
};

The add lambda uses a local variable and a Console.WriteLine call before returning. The greet lambda does not return anything, so it does not need a return statement.

Statement Lambdas in LINQ

LINQ methods like Where, Select, and Aggregate accept delegates. While expression lambdas are common, statement lambdas are valid as long as the method expects a delegate rather than an expression tree. For in-memory collections (IEnumerable<T>), you can use statement lambdas freely.

var doubled = numbers.Select(n =>
{
    int result = n * 2;
    return result;
}).ToList();

This is unnecessarily verbose for such a simple operation, but it demonstrates that the syntax is valid. Use statement lambdas in LINQ when the transformation requires more than a single expression.

Common Mistakes and Pitfalls with Statement Lambdas

A few mistakes are easy to make when writing statement lambdas.

Forgetting the Return Statement

If a delegate expects a return value, the statement lambda must have an explicit return statement. Missing it results in a compile-time error. For example:

Func<int, int> bad = x =>
{
    x * 2; // Error: not all code paths return a value
};

The compiler requires that every code path returns a value. This is a common source of errors for developers new to statement lambdas.

Using Statement Lambdas Where Expression Trees Are Required

As mentioned earlier, statement lambdas cannot be converted to expression trees. Trying to pass a statement lambda to an Expression<TDelegate> parameter will cause a compile-time error. For example:

IQueryable<int> query = ...;
query.Where(n =>
{
    return n > 5;
}); // Error: cannot convert statement lambda to expression tree

This is a fundamental limitation. If you need to build an expression tree, you must use an expression lambda.

Scope and Variable Capture

Statement lambdas capture variables from the enclosing scope just like expression lambdas. However, because they contain more code, it is easier to accidentally modify a captured variable in a way that causes subtle bugs. For example:

int counter = 0;
Func<int> increment = () =>
{
    counter++;
    return counter;
};

This is fine, but if you use the lambda in a loop, you need to be careful about closure semantics. The same rules apply as with expression lambdas.

Performance and Maintainability Considerations

Statement lambdas do not have a performance penalty compared to expression lambdas when used with delegates. Both compile to delegate instances, and the IL is similar. The main performance concern is the same as with any lambda: avoid unnecessary allocations in hot paths. If a statement lambda captures many variables, it may allocate a closure object. This is not unique to statement lambdas.

From a maintainability perspective, statement lambdas can be harder to read because they contain more logic. If a lambda grows beyond a few statements, consider extracting it into a named method. This improves readability and testability. For example, instead of a long statement lambda in a LINQ query, define a private method and pass a method group.

private static bool IsEvenAndPositive(int n)
{
    return n % 2 == 0 && n > 0;
}

// Usage
var result = numbers.Where(IsEvenAndPositive).ToList();

This is often clearer than a multi-line statement lambda.

Statement Lambdas with Async and Await

Statement lambdas are particularly useful when you need to use await inside a lambda. Expression lambdas can also be async, but if you have multiple awaits or other statements, a statement lambda is the natural choice.

Func<Task<int>> getValue = async () =>
{
    await Task.Delay(100);
    int value = 42;
    return value;
};

You can also use async statement lambdas as event handlers:

button.Click += async (sender, e) =>
{
    await LoadDataAsync();
    UpdateUI();
};

The async keyword is placed before the parameter list. The lambda returns a Task or Task<T> implicitly.

Statement Lambdas and Expression Trees: A Limitation

One of the most important limitations of statement lambdas is that they cannot be used to build expression trees. Expression trees represent code as data, and they are used by ORMs like Entity Framework to translate LINQ queries into SQL. The C# compiler only supports expression lambdas for expression tree conversion. If you try to assign a statement lambda to an Expression<TDelegate> variable, you get a compile-time error.

This means that if you are working with IQueryable<T> and want to build dynamic queries, you must use expression lambdas. Statement lambdas are only valid for delegates that execute locally.

Understanding this distinction is crucial for avoiding errors in LINQ-to-Entities scenarios.