Pattern Matching in Depth

Analogy categoryAnalogies

Scala's match expression is a vastly more powerful relative of a Java or C switch statement: it can match against literal values, types, case class structure, collection shapes, and guard conditions, and -- unlike switch -- it's an expression that produces a value rather than a statement, so val result = x match { case 1 => one; case _ => other } directly assigns the matched branch's result. Because match expressions are exhaustively checked by the compiler when matching against a sealed hierarchy, pattern matching becomes both a control-flow tool and a compile-time safety net.

🏏

Cricket analogy: A match expression is like an umpire's decision tree that also returns a verdict -- instead of just branching like a switch (out or not out), matching a ball outcome to Wide or NoBall directly produces the extra-run value used in the scorecard.

Matching on Types, Case Classes, and Guards

Pattern matching can deconstruct case classes directly in the case clause, binding their fields to new names in one step: case Circle(r) if r > 10 => big circle both extracts the radius into r and adds a guard condition (if r > 10) that must also hold for that branch to match. You can also match on runtime type with case s: String => ... (which uses isInstanceOf/asInstanceOf under the hood safely), combine multiple literal patterns with | as in case yes | y => true, and bind the whole matched value to a name with case p @ Point(x, y) => ... when you need both the deconstructed fields and the original object.

🏏

Cricket analogy: case Delivery(speed, _) if speed > 145 => express pace is like a speed-gun analyst flagging deliveries -- it both extracts the speed reading and applies a guard condition, so only genuinely express deliveries from bowlers with Shoaib Akhtar-caliber pace get flagged, not every delivery.

scala

sealed trait Shape
case class Circle(radius: Double) extends Shape
case class Rectangle(width: Double, height: Double) extends Shape
case class Triangle(base: Double, height: Double) extends Shape

def describe(shape: Shape): String = shape match {
  case Circle(r) if r > 10        => s"Large circle, radius $r"
  case Circle(r)                  => s"Circle, radius $r"
  case Rectangle(w, h) if w == h  => s"Square, side $w"
  case Rectangle(w, h)            => s"Rectangle ${w}x$h"
  case Triangle(b, h)             => s"Triangle, base=$b height=$h"
}

val numbers = List(1, 2, 3, 4)
numbers match {
  case Nil                      => println("empty")
  case head :: Nil               => println(s"single element: $head")
  case first :: second :: rest   => println(s"first=$first second=$second rest=$rest")
}

Matching Collections and Extractors

List patterns use the cons operator: case head :: tail => ... deconstructs a non-empty list into its first element and remaining list, case Nil => ... matches the empty list, and case first :: second :: rest => ... peels off two elements at once -- this recursive-deconstruction style is central to writing list-processing functions idiomatically in Scala. Beyond built-in collection patterns, you can write custom extractors by defining an unapply method (returning Option[T] for single-value extraction) or unapplySeq (returning Option[Seq[T]] for variable-arity extraction) on any object, letting you pattern-match against domain concepts that aren't case classes at all, such as regular expressions or custom parsing logic.

🏏

Cricket analogy: case opener :: rest => ... deconstructing a batting order is like a scorer peeling off the opening batter from the rest of the lineup -- the recursive pattern mirrors how a commentator analyzes openers vs the rest of the order one partnership at a time.

Sealed Hierarchies and Exhaustiveness

When a match expression covers a value of a sealed trait type, the Scala compiler performs exhaustiveness checking: if you forget to handle one of the sealed hierarchy's known subtypes, the compiler emits a warning (or an error, with -Xfatal-warnings enabled) at compile time rather than letting the gap surface as a scala.MatchError thrown at runtime when that unhandled case actually occurs. A wildcard case _ => ... branch technically satisfies exhaustiveness for any type, but using it on a sealed hierarchy defeats the purpose of exhaustiveness checking, since adding a new subtype later won't trigger a fresh compiler warning -- favor explicitly listing every case when the hierarchy is closed and small.

🏏

Cricket analogy: Exhaustiveness checking on sealed trait DismissalType is like the ICC auditing a scorer's dismissal-recording template before the season starts -- if Stumped is missing from the template, the audit catches it immediately, rather than the gap only being discovered when a wicketkeeper actually stumps a batter mid-match.

Because pattern matching binds new names from deconstructed values, it doubles as Scala's primary destructuring mechanism -- the same case Point(x, y) => syntax works in match, in for comprehensions, and in val Point(x, y) = somePoint value bindings.

A non-exhaustive match on a type the compiler can't fully verify (e.g., a plain non-sealed trait, or matching on Any) throws scala.MatchError at runtime for any unhandled input -- always add a case _ => fallback unless you've deliberately sealed the hierarchy and want the compiler's exhaustiveness warning.

match is an expression that produces a value, unlike Java/C's switch statement.
Case clauses can deconstruct case classes, bind names, add guard conditions with if, and combine literals with |.
List patterns use :: (cons) for deconstruction and Nil for the empty list, enabling recursive list processing.
Custom extractors implement unapply (single value) or unapplySeq (variable arity) to enable pattern matching on non-case-class types.
Matching on a sealed trait hierarchy gets compiler exhaustiveness checking, catching missing cases before runtime.
A wildcard case _ => satisfies exhaustiveness but silences the warning that would otherwise catch newly added subtypes.
An unhandled case at runtime throws scala.MatchError.