How do switch expressions differ from switch statements in C#? Explain arms, guards, discards, target typing of the result, exhaustiveness and SwitchExpressionException, tuple switches for state machines, and when a switch expression is the wrong tool.

How I would answer this in an interview

A switch statement chooses which statements to execute; a switch expression (C# 8) produces a value from the first matching arm. Switch expressions are concise, composable and checked for exhaustiveness — ideal for mapping inputs to outputs and for state machines. I'd cover arms, guards, discards, target typing, exhaustiveness and SwitchExpressionException, tuple switches, and when it's the wrong tool.

1. Statement vs expression

// Switch statement: control flow
switch (status)
{
    case OrderStatus.Paid:
        await ShipAsync(order, ct);
        break;
    case OrderStatus.Cancelled:
        await RefundAsync(order, ct);
        break;
    default:
        throw new InvalidOperationException();
}

// Switch expression: value
int statusCode = result switch
{
    Ok                 => 200,
    NotFound           => 404,
    ValidationFailed v => 422,
    _                  => 500
};

2. Arms, guards and discards

decimal Fee(Payment p) => p switch
{
    { Method: PaymentMethod.Card, Amount: < 10m }          => 0.30m,                // property + relational pattern
    { Method: PaymentMethod.Card } card when card.IsInternational => card.Amount * 0.035m,  // guard
    { Method: PaymentMethod.Card } card                    => card.Amount * 0.0175m,
    { Method: PaymentMethod.PayTo }                        => 0.10m,
    null                                                   => throw new ArgumentNullException(nameof(p)),
    _                                                      => 0m                    // discard
};

• Each arm: pattern [when guard] => expression. First match wins, top to bottom.
• when adds arbitrary conditions (but the compiler can't use them for exhaustiveness).
• _ matches anything; place it last.
• throw expressions are allowed as arm results.

3. Target typing of the result

The switch expression's type is the best common type of its arms or, if there isn't one, the target type (C# 9):

IShape s = kind switch { "circle" => new Circle(1), "square" => new Square(2), _ => throw new ArgumentException() };
int? limit = tier switch { Tier.Gold => 100, Tier.Silver => 50, _ => null };   // null arm OK because target is int?

Without a target type (var x = kind switch { ... Circle ... Square ... }), it fails to compile if there's no common type.

4. Exhaustiveness and SwitchExpressionException

• The compiler warns (CS8509) when not every possible input is handled. For enums, you need _ even when all named values are listed, because enums can hold any integer.
• At run time, an unmatched input throws SwitchExpressionException (with the unmatched value in UnmatchedValue).
• Treat CS8509 as an error and add an explicit discard that throws a meaningful exception (ArgumentOutOfRangeException/UnreachableException) for impossible cases.

5. Tuple switches for state machines

public static OrderState Next(OrderState state, OrderTrigger trigger) => (state, trigger) switch
{
    (OrderState.Draft,    OrderTrigger.Submit)  => OrderState.Pending,
    (OrderState.Pending,  OrderTrigger.Pay)     => OrderState.Paid,
    (OrderState.Pending,  OrderTrigger.Cancel)  => OrderState.Cancelled,
    (OrderState.Paid,     OrderTrigger.Ship)    => OrderState.Shipped,
    (OrderState.Paid,     OrderTrigger.Cancel)  => OrderState.Refunding,
    (_, _) => throw new InvalidOperationException($"Cannot {trigger} when {state}")
};

The transition table is readable and every valid transition is in one place; invalid ones throw. For larger workflows with side effects, guards and persistence, a library (Stateless) or a dedicated state pattern may be better.

6. When a switch expression is the wrong tool

• Arms need multiple statements or side effects (I/O, logging, several updates) — use a switch statement or methods.
• The same type switch is duplicated in many places for an open hierarchy — polymorphism is better.
• Arms have long, complex expressions — extract methods or use a lookup table.
• The mapping is data, not logic (e.g. 200 country codes → names) — use a dictionary/FrozenDictionary or configuration.
• You need async work in arms — you can return tasks (=> SendAsync(...)) but awaiting inside arms isn't possible; a switch statement with await reads better.

7. A production example

Order status transitions were spread across services with if (order.Status == Paid && action == "ship") checks; an invalid transition (shipping a cancelled order) slipped through. We centralised transitions in a tuple switch expression like the one above, with tests for every valid and invalid pair. Adding "Partially Shipped" later meant adding two arms and tests, and the discard arm made invalid transitions fail loudly.