Learn the vocabulary of checking a value against several possible shapes and extracting data from whichever matches.
0 / 5 completed
1 / 5
At standup, a dev mentions writing a single construct that checks a value against several possible shapes or variants in order, extracting relevant data from whichever shape actually matches, instead of a chain of separate manual type checks and casts. What is this technique called?
Pattern matching is exactly this: a single language construct that checks a value against several possible shapes or variants in order, and for whichever one actually matches, extracts the relevant data directly, rather than requiring a chain of separate manual type checks, casts, and field accesses written out by hand. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This check-and-extract-in-one-construct behavior is exactly why pattern matching pairs so naturally with algebraic data types, letting each of a type's distinct variants be handled clearly and concisely.
2 / 5
During a design review, the team uses pattern matching to handle each variant of an algebraic data type, and the compiler flags an error if any variant is left unhandled. Which capability does this provide?
Pattern matching here provides exhaustiveness checking, since the compiler can verify at compile time that every possible variant of the algebraic data type has an explicit case in the pattern match handling it, flagging an error the moment a new variant is added but left unhandled somewhere. A chain of manual type checks with no compile-time verification would only reveal a missed case at runtime, if a value of the unhandled variant actually occurs, rather than catching it up front. This compile-time exhaustiveness guarantee is exactly why pattern matching over algebraic data types catches an entire class of missed-case bugs before the code ever runs.
3 / 5
In a code review, a dev notices a function handles a value's several possible variants using a long chain of manual type checks, casts, and field accesses written by hand, instead of a single pattern-matching construct that the compiler could check for exhaustiveness. What does this represent?
This is a missed pattern-matching opportunity, since a long chain of manual type checks, casts, and field accesses gives the compiler no way to verify that every possible variant has actually been handled, when a single pattern-matching construct over the same variants would let the compiler check exhaustiveness and flag any variant left unhandled. A cache eviction policy is an unrelated concept about discarded cache entries. This manual-chain-instead-of-pattern-matching pattern is exactly the kind of missed compile-time safety a reviewer flags when a value's shape is already modeled as a set of distinct variants.
4 / 5
An incident report shows a bug reached production because a new variant was added to a type, but a function handling that type's variants through a manually written chain of type checks was never updated, silently falling through with no case for the new variant. What practice would prevent this?
Rewriting the function using pattern matching over the type's variants lets the compiler flag an error the moment a new variant is added without a corresponding case in every pattern match handling that type, which is exactly the fix for the silently-falling-through bug described in this incident. Continuing to rely on a manually written chain of type checks regardless of how easy it is to forget updating it is exactly what let the new variant slip through unhandled. This compiler-enforced exhaustiveness is a standard fix for exactly this class of bug, where a type gains a new variant that some handling code elsewhere fails to account for.
5 / 5
During a PR review, a teammate asks why the team relies on pattern matching's compiler-enforced exhaustiveness instead of just adding a default fallback case at the end of a chain of manual type checks to catch anything unhandled. What is the reasoning?
A default fallback case silently absorbs any variant that isn't explicitly handled, including a genuinely new variant that might actually need its own distinct logic, quietly masking the gap instead of surfacing it, while pattern matching's exhaustiveness check forces a developer to consciously decide, at compile time, how to handle every single variant, including one that's newly added later. This is exactly why relying on pattern matching's exhaustiveness, rather than a catch-all default case, is preferred whenever a missed variant should be caught and addressed deliberately instead of silently swallowed.