A classic switch statement tells the computer what to do. A switch expression tells it what value to produce — and that small shift changes everything about how safe and concise it can be.

You already learned switch statements back in Control Flow, and you just spent the last lesson learning how rich a single pattern (is Circle { Radius: > 10 }) can be. Now imagine combining the two: what if switch could test a whole series of patterns, one after another, and directly produce a value — instead of just running statements and hoping every branch remembers to assign one?

That's exactly what a switch expression is. It takes everything you learned about patterns in the last lesson and puts them to work choosing between values, as compactly and safely as C# gets.

In this lesson, you'll learn switch expressions (=>), how they differ from classic switch statements, pattern-based switch arms, when guards for extra conditions, and how the compiler checks your cases for exhaustiveness — plus the discard _ arm that catches everything else.

What Is It?

The Simple Explanation

A switch expression is a compact way to say "look at this value, find the first matching case, and give me back whatever that case says." Unlike a classic switch statement — which runs a block of statements per case — a switch expression's entire job is to evaluate to a single value, like a supercharged ternary operator that can handle many cases instead of just two.

The Technical Definition

A switch expression (C# 8) is an expression-form of switch: value switch { pattern1 => result1, pattern2 => result2, ... }. Each arm pairs a pattern (any of the patterns from the previous lesson — type, property, relational, or a combination) with a result expression, connected by =>. Arms are tried top-to-bottom; the first one whose pattern matches supplies the expression's value, and evaluation stops there. An optional when guard adds an extra boolean condition to a pattern. The compiler performs exhaustiveness analysis: if it can determine that not every possible input is covered, it emits a warning (and, since no arm matched at runtime for an uncovered case, throws a SwitchExpressionException) — which is why a final discard arm (_ => ...) is so commonly used to guarantee every case is handled.

Why Does It Exist?

The Problem

Assigning a value based on several conditions with a classic switch statement is more ceremony than the logic deserves:

decimal discountRate;
switch (customerTier)
{
    case "Bronze":
        discountRate = 0.02m;
        break;
    case "Silver":
        discountRate = 0.05m;
        break;
    case "Gold":
        discountRate = 0.10m;
        break;
    default:
        discountRate = 0m;
        break;
}

Fourteen lines, and the risk of a real bug lurking in it: if you forget to assign discountRate in one branch (or forget a break and accidentally fall through), the compiler may not catch it until much later, if at all.

The Need

Developers needed a form of switch whose entire purpose is producing a value — where the compiler can verify every branch actually returns something of the right type, where there's no break to forget, and where the new pattern-matching vocabulary (type, property, relational patterns) could be used directly as the case labels.

The Solution

The switch expression collapses the same logic into a direct assignment:

decimal discountRate = customerTier switch
{
    "Bronze" => 0.02m,
    "Silver" => 0.05m,
    "Gold" => 0.10m,
    _ => 0m
};

Every arm's expression must produce a compatible type, there's no break to forget, and the compiler checks that you've covered your bases.

Big Picture

How It Works

string sizeLabel = weightKg switch
{
    < 1 => "Envelope",
    < 5 => "Small",
    < 20 => "Medium",
    _ => "Large"
};

decimal shippingCost = order switch
{
    { Destination: "International", WeightKg: > 20 } => 75m,
    { Destination: "International" } => 35m,
    { Destination: "Domestic", WeightKg: <= 5 } => 5m,
    { Destination: "Domestic" } => 12m,
    _ => 15m
};

string status = order switch
{
    { IsCancelled: true } => "Cancelled",
    { ShippedDate: not null } when order.ShippedDate > DateTime.UtcNow.AddDays(-2) => "Recently shipped",
    { ShippedDate: not null } => "Shipped",
    _ => "Processing"
};

//  CS8509: the switch expression does not handle all possible values
string Describe(int score) => score switch
{
    >= 90 => "A",
    >= 80 => "B",
    >= 70 => "C"
    // missing a case for anything below 70!
};

//  The discard arm _ guarantees every remaining value is handled
string Describe(int score) => score switch
{
    >= 90 => "A",
    >= 80 => "B",
    >= 70 => "C",
    _ => "F"
};

Simple Example

string ClassifyGrade(int score) => score switch
{
    < 0 or > 100 => throw new ArgumentOutOfRangeException(nameof(score)),
    >= 90 => "A",
    >= 80 => "B",
    >= 70 => "C",
    >= 60 => "D",
    _ => "F"
};

Console.WriteLine(ClassifyGrade(95)); // "A"
Console.WriteLine(ClassifyGrade(50)); // "F"

Code → Meaning → Result: Each arm reads as a direct rule ("90 or above is an A"), arms are checked top to bottom so the highest threshold that matches wins, and a switch arm can even throw as its result expression — useful for turning invalid input into an immediate, clear error as part of the same expression.

Real-World Example

A discount-tier calculator for an e-commerce order, combining a property pattern, a when guard, and a guaranteed fallback:

public record Customer(string Tier, int YearsAsMember, decimal LifetimeSpend);

decimal GetDiscountRate(Customer customer) => customer switch
{
    { Tier: "Platinum" } => 0.20m,
    { Tier: "Gold", YearsAsMember: >= 5 } => 0.15m,
    { Tier: "Gold" } => 0.10m,
    { LifetimeSpend: > 10_000m } when customer.YearsAsMember >= 2 => 0.08m,
    { Tier: "Silver" } => 0.05m,
    _ => 0.0m
};

var customer = new Customer("Gold", YearsAsMember: 6, LifetimeSpend: 4200m);
Console.WriteLine(GetDiscountRate(customer)); // 0.15 — Gold AND 5+ years wins over plain Gold

Notice the order of the arms matters: { Tier: "Gold", YearsAsMember: >= 5 } is checked before the plain { Tier: "Gold" } arm, so a long-standing Gold member gets the better rate — if the two arms were reversed, the more general one would always win first and the specific rule would never be reached. This is exactly the "first match wins" behavior to keep in mind when ordering your arms from most-specific to least-specific.

Under the Hood

Common Confusion

1. Switch expression syntax vs switch statement syntax — don't mix them up

A switch statement uses case value: and needs break; a switch expression uses pattern => and has no case or break at all, using commas between arms instead. They look related but the syntax genuinely doesn't interchange — you can't add a break to a switch expression arm, and you can't use => in a switch statement's case label.

2. "First match wins" — order matters, especially with overlapping patterns

If two arms could both match the same value, whichever comes first in the expression is the one that fires — the rest are never even checked for that value. This is why the real-world example above lists the more specific { Tier: "Gold", YearsAsMember: >= 5 } arm before the more general { Tier: "Gold" } arm.

3. A compiler warning about exhaustiveness isn't the same as a guarantee against crashes

The compiler's exhaustiveness check is best-effort static analysis — for patterns based on runtime property values (like { Tier: "Gold" }) it generally can't prove every possible string is covered, so it won't warn even though a truly unexpected Tier value could still fall through with no matching arm and throw at runtime. Always include a discard (_) arm unless you are certain every case is genuinely and provably covered.

Common Mistakes

Mistake 1 — Omitting the discard arm and getting a runtime crash later

Assuming a set of specific-value arms covers everything, without a final _:

string label = status switch
{
    "Active" => "",
    "Inactive" => ""
    // any other string throws SwitchExpressionException at runtime
};

Add _ => "" (or a deliberate, informative throw) as the final arm, so unexpected values are handled explicitly and predictably.

Mistake 2 — Ordering arms so a general pattern shadows a specific one

decimal rate = customer switch
{
    { Tier: "Gold" } => 0.10m,                       //  this matches first...
    { Tier: "Gold", YearsAsMember: >= 5 } => 0.15m,   // ...so this is unreachable!
    _ => 0.0m
};

List more specific patterns before more general ones that could also match the same value. Some IDEs and the compiler will even warn about an unreachable arm in obvious cases.

Mistake 3 — Reaching for a switch expression when a switch statement is actually the right tool

A switch expression is for producing a value. If what you actually need is to run several different side effects (log something, call a different service, update multiple pieces of state) per case, forcing that into a switch expression — often by discarding a return value or awkwardly stuffing statements into a local function — usually reads worse than a plain switch statement. Use the tool that matches the shape of what you're doing: value selection → switch expression; multi-step actions → switch statement.

When Should I Use It?

• Use a switch expression whenever the goal is "pick one value out of several possibilities based on patterns" — discount rates, classification labels, mapping one type to another.
• Combine it with the pattern vocabulary from the previous lesson (type, property, relational, and/or/not) for genuinely rich, readable case logic.
• Use a classic switch statement instead when each case needs to perform multiple statements or side effects rather than produce one value.
• Always include a discard (_) arm unless you're certain the compiler can prove exhaustiveness on its own (which, in practice, is mostly limited to enums and a few other closed sets of values).

Mental Model

Key Takeaway

Check Your Understanding

You've seen how switch expressions combine everything from the pattern-matching lesson with direct value production. Let's check your understanding.

decimal GetDiscountRate(Customer c) => c switch
{
    { Tier: "Gold" } => 0.10m,
    { Tier: "Gold", YearsAsMember: >= 5 } => 0.15m,
    _ => 0.0m
};

You can now express rich, pattern-based decision logic as a single readable value expression instead of a scaffold of statements.

dotnetmadeeasy.com — Learn C# and .NET, the right way.