The humble switch statement has been a programming staple for decades, but modern languages are pushing far beyond simple value comparisons. Today’s pattern matching capabilities transform switch statements from basic control flow into powerful destructuring and matching engines that make code more expressive and safer.

The Evolution of Switch

Traditional switch statements in languages like C and Java were limited to comparing values against constants. You’d write something like checking if a number equals 1, 2, or 3, and that was about it. But developers needed more. They needed to destructure complex objects, match against types, and express sophisticated conditional logic without nesting endless if-else chains.

Modern pattern matching emerged from functional programming languages like ML and Haskell, where it’s been a core feature for decades. Now, mainstream languages are catching up. C# has had pattern matching since version 7.0, with continuous improvements. Java introduced it as a preview in version 14 and has been enhancing it through subsequent releases. Even JavaScript is getting in on the action with a Stage 1 proposal for pattern matching.

Destructuring: Unpacking Complex Data

One of the most powerful aspects of modern pattern matching is destructuring—the ability to pull apart data structures right in the match expression. Instead of accessing properties line by line, you can extract values directly in the pattern.

Consider handling different shapes in a graphics application. With traditional switch, you’d need to cast and access properties separately:

// Old way - verbose and repetitive
switch (shape.Type)
{
 case ShapeType.Circle:
 var circle = (Circle)shape;
 Console.WriteLine($"Circle with radius {circle.Radius}");
 break;
 case ShapeType.Rectangle:
 var rect = (Rectangle)shape;
 Console.WriteLine($"Rectangle {rect.Width}x{rect.Height}");
 break;
}

With pattern matching, you destructure inline:

// Modern pattern matching
switch (shape)
{
 case Circle { Radius: var r }:
 Console.WriteLine($"Circle with radius {r}");
 break;
 case Rectangle { Width: var w, Height: var h }:
 Console.WriteLine($"Rectangle {w}x{h}");
 break;
}

The syntax becomes declarative. You’re describing what you’re looking for, and the language handles the extraction.

Guards: When Types Aren’t Enough

Sometimes you need to match on type and some condition. That’s where guards come in—additional conditions that refine your pattern. They let you express “match this type when this condition is also true.”

Here’s a real-world example processing orders:

decimal CalculateDiscount(Order order) => order switch
{
 { Items.Count: > 10, TotalAmount: > 1000 } => 0.20m,
 { IsFirstOrder: true, TotalAmount: > 100 } => 0.15m,
 { CustomerType: CustomerType.Premium } => 0.10m,
 _ => 0m
};

Each pattern combines type checking with property conditions. The first match wins, so order matters. This reads almost like business rules—if the order has more than 10 items and costs over $1000, apply a 20% discount.

Algebraic Data Types and Exhaustiveness

Pattern matching truly shines when combined with algebraic data types—types that are defined by being one of a fixed set of variants. Think of a result that’s either success or failure, or an optional value that’s either something or nothing.

When the compiler knows all possible variants, it can enforce exhaustiveness—ensuring you’ve handled every case. This catches bugs at compile time that would otherwise lurk until runtime.

// Discriminated union in C# (using record types)
abstract record Result;
record Success(string Data) : Result;
record Error(string Message) : Result;

string HandleResult(Result result) => result switch
{
 Success(var data) => $"Got data: {data}",
 Error(var msg) => $"Failed: {msg}"
 // Compiler ensures all cases covered
};

If you add a new result type later and forget to handle it, the compiler will complain. This is defensive programming at its finest.

List and Collection Patterns

Recent pattern matching enhancements extend to collections. You can match against list structures, checking for specific elements at specific positions or matching based on length.

C# 11 introduced list patterns that let you destructure arrays and lists:

int[] numbers = { 1, 2, 3, 4, 5 };

string Describe(int[] arr) => arr switch
{
 [] => "Empty",
 [var x] => $"Single element: {x}",
 [var first, .., var last] => $"First: {first}, Last: {last}",
 [1, 2, ..] => "Starts with 1, 2",
 _ => "Something else"
};

The .. slice pattern matches zero or more elements, letting you focus on the parts you care about while ignoring the rest.

Real-World Impact: Parser and AST Handling

Pattern matching isn’t just syntactic sugar—it fundamentally changes how you structure code. Nowhere is this clearer than in compilers and parsers, where you’re constantly matching against tree structures.

A typical AST (Abstract Syntax Tree) evaluation might look like:

int Evaluate(Expression expr) => expr switch
{
 Literal { Value: var v } => v,
 Add { Left: var l, Right: var r } => Evaluate(l) + Evaluate(r),
 Multiply { Left: var l, Right: var r } => Evaluate(l) * Evaluate(r),
 Negate { Inner: var inner } => -Evaluate(inner),
 _ => throw new InvalidOperationException()
};

This is dramatically clearer than nested if-else statements checking types and casting. The structure of your code mirrors the structure of your data.

Performance Considerations

Modern compilers are smart about pattern matching. They generate efficient dispatch code, often using jump tables or decision trees similar to what traditional switch statements use. The additional expressiveness doesn’t come with a runtime penalty.

That said, complex nested patterns can impact compilation time, and certain patterns (like those with many guards) may compile to sequential checks rather than optimized dispatches. The readability benefits usually outweigh minor performance differences, but it’s worth profiling if you’re matching in a hot loop.

The JavaScript Future

While JavaScript doesn’t yet have native pattern matching, the proposal shows where the language is heading:

// Proposed JavaScript syntax
match (value) {
 when ({ type: 'circle', radius: r }) -> `Circle: ${r}`,
 when ({ type: 'rect', width: w, height: h }) -> `Rect: ${w}x${h}`,
 when (Number) if (value > 100) -> 'Large number',
 default -> 'Unknown'
}

This would bring JavaScript in line with modern pattern matching while maintaining the language’s flexible nature. Libraries like ts-pattern already provide similar functionality for TypeScript users today.

Beyond Types: Pattern Matching Philosophy

The real power of pattern matching isn’t in the syntax—it’s in the mindset shift. You stop thinking about control flow as a series of checks and branches, and start thinking declaratively about the shape of your data.

When you write a pattern match, you’re documenting the structure you expect. Future maintainers can read your patterns and immediately understand what data shapes your code handles. The compiler becomes your ally, ensuring you don’t miss cases.

This pairs beautifully with functional programming principles: immutability, algebraic data types, and expression-oriented programming. Your functions become pipelines of transformations, with pattern matching serving as the routing layer that directs data through the appropriate logic.

Useful Links

Language Documentation:

• C# Pattern Matching – Microsoft’s comprehensive guide to C# pattern matching features
• Java Pattern Matching – JEP 441: Pattern Matching for switch
• Rust Pattern Matching – The Rust Programming Language book chapter on patterns

Proposals and Specifications:

• JavaScript Pattern Matching Proposal – TC39 proposal for adding pattern matching to JavaScript
• TypeScript Pattern Matching Discussion – Long-running discussion about pattern matching in TypeScript

Tools and Libraries:

• ts-pattern – Pattern matching library for TypeScript
• Rematch – Pattern matching utilities for JavaScript

Further Reading:

• Pattern Matching for Java – Brian Goetz’s comprehensive exploration of pattern matching
• Exhaustiveness Checking – Cornell CS course material on exhaustiveness in pattern matching