Records, Patterns & Sealed Classes (Dart 3)

By the end of this lesson you will be able to bundle several values into a lightweight record without writing a class, read and write every kind of pattern Dart 3 offers (matching AND pulling values out in one step), place those patterns everywhere Dart allows them (declarations, assignment, switch, if-case, for-in), and model a fixed, closed set of variants with a sealed class so the compiler — not a bug report — catches a forgotten case.

1. Records: bundling values without a class

Dart has two record styles, and you can mix them in one record:

• Positional — (1, 'a'). Fields are accessed by an auto-generated name based on position: $1, $2, and so on.
• Named — (x: 1, y: 2). Fields are accessed by the name you gave them: .x, .y. Order doesn't matter for named fields.
• Mixed — (10, 'x', y: 20) — positional fields first, named fields after.

The type of a record is written the same way: (int, String) is the type of any positional record with an int then a String; ({int x, int y}) is the type of a named record with those two fields.

The same thing as runnable Dart — positional, named and mixed records, their types, how they print, and the two compile errors you meet first (both confirmed with dart analyze) (the // => lines are the exact output, checked by verify/d11.dart):

Input size → what's feasible: a record has a fixed number of fields written in your source (2 to 5 is typical), so creating one and reading a field are both O(1); when the count varies at runtime (n = 10⁶ values), use a List instead.

2. Equality, identity & immutability

Records automatically get a structural == and a matching hashCode: two records are equal exactly when they have the same shape (same field names/positions) and every field is ==. This is generated for free — you never write == or hashCode for a record yourself.

The same thing as runnable Dart — value equality for records, identity equality for a plain class, and what const guarantees (the // => lines are the exact output, checked by verify/d11.dart):

Input size → what's feasible: == on two records compares their k fields, O(k); comparing 10⁶ pairs of 2-field records is about 2·10⁶ field comparisons.

The same thing as runnable Dart — the rejected assignment (kept as a comment with its exact error), the "build a new record" way to change one, and the one catch: a mutable object stored inside a record can still change (the // => lines are the exact output, checked by verify/d11.dart):

That last line is the difference between shallow and deep immutability: the record's own fields can never be re-pointed, but they can point at something mutable. Lesson D22 · Mutable vs Immutable explains this properly, including how to make a deep copy.

The same thing as runnable Dart — because records compare by value they work as Set elements and Map keys, which a plain class (no ==) cannot (the // => lines are the exact output, checked by verify/d11.dart):

Input size → what's feasible: building a Set<(int, int)> of n = 10⁶ cells costs about 10⁶ hash computations of 2 fields each — fine for a 1000 × 1000 grid search.

3. Returning multiple values; records vs. classes

Before records, returning "two things" from a function usually meant writing a small class just to carry them, or (worse) stuffing them into a List and hoping everyone remembers which index is which. A record lets a function return several values directly, with each one clearly named:

The same thing as runnable Dart — the same one-pass minMax (full source in question q14), used two ways: by field name and destructured (the // => lines are the exact output, checked by verify/d11.dart):

Input size → what's feasible: returning a record adds O(1) to whatever the function does: minMax is one pass, ≈ 10⁷ reads for n = 10⁷; sorting instead would cost ≈ 2.3·10⁸ steps.

4. What is pattern matching? Every pattern kind, one at a time

So "pattern matching" always does up to two things at once: (1) test whether a value has a certain shape, and (2) destructure it — bind the pieces you care about to new variable names, in the same step. Dart checks each pattern against a value and answers only true (matched — with any bindings filled in) or false (no match, nothing bound).

Dart 3 has fourteen kinds of pattern (the logical pattern counts once for && and ||). Step through each one below and watch it tested against a value that matches, then one that doesn't:

The same thing as runnable Dart — the first seven kinds — constant, variable, wildcard, typed, relational, logical (&& and ||) and parenthesized — each tried on a value that matches and one that does not (the // => lines are the exact output, checked by verify/d11.dart):

The same thing as runnable Dart — the null-check, null-assert and cast patterns, including the exact TypeError messages the two throwing ones produce (the // => lines are the exact output, checked by verify/d11.dart):

The same thing as runnable Dart — the four structural kinds — list (with ...rest and a bare ...), map, record and object — plus the :name shorthand (the // => lines are the exact output, checked by verify/d11.dart):

Input size → what's feasible: constant, relational, typed, null and wildcard tests are O(1); a list pattern with ...rest copies the remaining elements, so for n = 10⁶ it costs ≈ 10⁶ element copies — harmless once, 10¹² steps if repeated inside a 10⁶-iteration loop. Map patterns do one hash lookup per key you list.

5. Where patterns appear

Patterns aren't only for switch. Dart lets you write them in five places:

• Variable declarations — var (a, b) = (1, 2); destructures immediately.
• Assignment — (a, b) = (b, a); is a clean, temp-variable-free swap.
• switch statements & expressions — tests a value against a list of patterns, top to bottom (you saw the basics of this in D06; this lesson adds the remaining pattern kinds).
• if-case — if (value case pattern) { ... } tries ONE pattern without a full switch; can carry an optional when guard.
• for-in — for (final (a, b) in pairs) { ... } destructures every element as it's pulled from an iterable.

The same thing as runnable Dart — declaration and assignment patterns, a wrong-length list in a declaration (it throws), and the refutable-pattern compile error (the // => lines are the exact output, checked by verify/d11.dart):

An if-case can carry an optional when guard — an extra boolean condition checked only after the pattern itself matches:

The same thing as runnable Dart — httpBucket and two more if-case forms: a guard on a typed pattern, and an else branch (the // => lines are the exact output, checked by verify/d11.dart):

for-in can destructure each element as it's pulled out of any Iterable, including a List of records:

The same thing as runnable Dart — for-in destructuring of a list of records, of map entries (an object pattern on MapEntry) and of .indexed (the // => lines are the exact output, checked by verify/d11.dart):

And the two forms of switch that take patterns. A switch expression produces a value and every case ends in =>; a switch statement runs statements and never falls through to the next case, so there is no break. In both, cases are tried top to bottom and the first match wins, so put the specific cases (with guards) before the general ones:

Input size → what's feasible: a destructuring for-in is the same O(n) as a plain one; a switch with c cases tests at most c patterns per value, so 10⁷ values × 8 cases ≈ 8·10⁷ pattern tests (about a second).

6. Sealed classes & exhaustiveness checking

sealed class Shape {} declares that every direct subclass of Shape must be declared in the same library (file). This turns Shape into a closed set of variants — often called an algebraic data type in other languages — and unlocks exhaustiveness checking: a switch over a sealed type must handle every subtype (or include a wildcard _), or it fails to compile.

The same thing as runnable Dart — the exhaustive area switch from the player (full classes in question q16), with the two compile errors kept as comments (the // => lines are the exact output, checked by verify/d11.dart):

The same thing as runnable Dart — what the compiler counts as exhaustive: every enum value, both bool values, every combination of a record of bools, every subtype plus null for a nullable sealed type, and the guard trap and its fix (the // => lines are the exact output, checked by verify/d11.dart):

Input size → what's feasible: exhaustiveness is checked once by the analyzer, so it costs nothing at runtime; at runtime a switch over k subtypes does at most k type tests, O(k).

7. Class modifiers: sealed, final, base and interface

First, one word: a library in Dart is, for our purposes, one .dart file (and everything it pulls in with part). The modifiers below only restrict what code in other libraries may do; inside the file that declares the class, you can always do everything. That is why the rules need two files to show an error and why the panel below runs in one file and quotes the errors from a two-file test.

The same thing as runnable Dart — one declaration of each modifier and what you can do with it inside the declaring file. The cross-library errors are quoted from dart analyze on a two-file test package (the // => lines are the exact output, checked by verify/d11.dart):

Input size → what's feasible: modifiers are compile-time rules, so they cost nothing at runtime; sealed adds the exhaustiveness check described in section 6.

8. Real use: parsing JSON safely

Decoded JSON in Dart usually arrives as Map<String, Object?> — the value types aren't known until you check them. A map pattern checks the presence AND type of specific keys in one step, which is exactly what safe JSON parsing needs:

The same thing as runnable Dart — a describeJson switch with five map-pattern cases tried in order: extra keys, a wrong-typed value falling through, a nested map pattern, and a list pattern inside a map pattern (the // => lines are the exact output, checked by verify/d11.dart):

Input size → what's feasible: a map pattern does one hash lookup per key you list, so checking 3 keys costs ≈ 3 steps whether the map has 10 keys or 10⁶.

9. Real use: an expression evaluator & state machines

A tiny calculator's expression tree is a classic use for a sealed hierarchy: an Expr is either a literal number, an addition, a multiplication, or a negation — nothing else. Evaluating it is then just a switch that recurses into the sub-expressions:

The same thing as runnable Dart — building the tree from the player, printing it, evaluating it, and simplifying (classes and functions are in questions q21 and q22) (the // => lines are the exact output, checked by verify/d11.dart):

Sealed classes are also a natural fit for a state machine: a traffic light is either red, yellow, or green (modelled here with a plain enum, which gets the very same exhaustiveness checking as a sealed class), and a transition function is one exhaustive switch mapping each state to the next. You'll trace a full red → green → yellow → red cycle in the interview bank (Medium tier) — the same "closed set of cases, checked at compile time" idea scales from three colors up to arbitrarily complex sealed hierarchies.

The same thing as runnable Dart — the red → green → yellow → red cycle driven by one exhaustive switch (LightColor and nextLight are in question q17) (the // => lines are the exact output, checked by verify/d11.dart):

Input size → what's feasible: evalExpr visits each node once, so n = 10⁶ nodes is about 10⁶ steps, but recursion depth equals the tree height: keep the height below about 2000 (stack limits vary by platform; a local Dart 3.11 test overflowed only between 20,000 and 50,000 nested calls, so 2000 is a safe margin) or use an explicit stack. A state machine transition is O(1).

Quiz

Interview questions

Cheat sheet