In a match expression, what does binding a value's parts inside the pattern give you that reading fields in the branch body does not?

juniormust knowfreq 62%

answer

one construct, two jobs
test the shape, name the parts
bindings arrive already in scope
nested pattern reaches through a layer
wildcard matches, binds no name

basics

~20 s

Binding in the pattern makes one construct do two jobs: it tests that the value has the case's shape and names the parts of that shape at the same time. The branch body starts with named parts instead of shape checks and accessor calls.

solid answer

~40 s

A pattern is the shape a case is written for. Matching a value against it tests whether the value has that shape and, when it does, binds each hole in the shape to a name the case body can use. case Booking(guest, Range(start, end)) selects only a booking whose stay is a two-ended range, and inside that case guest, start and end already exist. Doing it in the body instead means checking the shape yourself, then pulling parts out with accessors, and usually re-asserting a shape the check already established. Patterns also nest, so one pattern reaches through a booking into its stay; the body never names the intermediate value it does not care about. A wildcard fills a position you are not asking about and binds nothing.

A pattern is the shape a case is written for. Matching a value against it tests whether the value has that shape and, when it does, binds each hole in the shape to a name the case body can use. `case Booking(guest, Range(start, end))` selects only a booking whose stay is a two-ended range, and inside that case `guest`, `start` and `end` already exist. Doing it in the body instead means checking the shape yourself, then pulling parts out with accessors, and usually re-asserting a shape the check already established. Patterns also nest, so one pattern reaches through a booking into its stay; the body never names the intermediate value it does not care about. A wildcard fills a position you are not asking about and binds nothing.

code

pseudocode · 7 lines

pseudocode

function quote(request)
    if isBooking(request) and isRange(request.stay)
        guest = request.guest
        start = request.stay.start
        end   = request.stay.end
        return nightlyQuote(guest, start, end)
    return fallbackQuote(request)

go deeper

for a junior

Be able to say the two jobs in one breath: the pattern decides whether the case applies, and it names the parts that case needs. Then show a two-level pattern reaching into a nested value.

for a middle

Explain what the body-side alternative costs: a hand-written shape test per layer that can drift from the extraction beside it, and intermediate values the case never really wanted.

for a senior

Show the judgment about readability: a wildcard where a part is irrelevant, names only where they are used, and cases whose first line tells a reviewer exactly which situation is being handled.

for a principal

Frame it as a house convention. Deciding that shape decisions are taken in patterns rather than in branch bodies is what keeps the check and the extraction from diverging as a codebase grows.

One construct, two jobs

A pattern describes the shape a case is written for, and matching a value against it does two things in the same step.

It tests: does this value have that shape? A booking whose stay is a two-ended date range matches Booking(guest, Range(start, end)); a booking whose stay is open-ended does not.
It binds: every hole in the shape becomes a local name holding the part that filled it. Inside the case, guest, start and end are already in scope.

That is the whole of what "destructuring in the pattern" means. The alternative - test the shape, then extract fields with accessors in the body - splits those two jobs apart, and every difference below follows from that split.

Nesting reaches through a layer

Patterns compose the way the data composes. A booking is a product: it holds a guest and a stay. A stay is a sum: it is either a two-ended range or an open-ended start. A nested pattern walks both in one expression.

Booking(guest, Range(start, end)) matches a booking whose stay is a range, naming three parts at two different depths.
Booking(_, OpenEnded(start)) matches the other stay shape and names only the start.
Booking(guest, _) matches any booking at all and names only the guest.

The depth of the pattern is the depth of the reach. The body never has to hold the stay in a variable so it can ask it a second question, which is why a destructured case usually reads as one sentence about the one situation it handles.

A wildcard is a part you are not asking about

A wildcard matches whatever sits in its position and binds nothing. It is not a name: nothing in the body can read it. Two consequences are worth saying out loud.

It still occupies a position, so the pattern's shape is unchanged - Booking(_, _) is still a two-part booking, just one whose parts this case ignores.
Writing a wildcard rather than an unused name states the intent directly: this part does not participate in this case, so no reader goes hunting for where it is used.

Scope of what a pattern binds

The names a pattern binds belong to that case only. They come into existence when that case is selected and are not visible in the other cases or after the match finishes. Two cases may bind the same name from different positions without colliding, because they are different bindings in different scopes. This is why reading a destructured match is local work: the meaning of start is fixed by the one pattern directly above it.

The body-side version, and what it costs

Concern	Bound in the pattern	Extracted in the body
Shape test	Part of the case; the case is chosen only if the shape fits	A separate condition the author must write and keep correct
Naming the parts	Automatic, at the moment the test succeeds	Manual accessor calls after the test
Nested shapes	One pattern reaches every depth	An intermediate value per layer, each usually re-tested
When the shape does not fit	Control moves on to the next case	The author must remember to fall through or return
Reading the code	The situation handled is visible on the case line	The situation is spread over the first few lines of the body

The practical failure of the body-side version is the third and fourth rows. Each extra layer adds a test the author can forget, and a test written by hand can disagree with the extraction that follows it - the shape is checked one way and taken apart another. A pattern cannot drift from itself, because the test and the extraction are the same piece of text.

What an interviewer is listening for

That you say both jobs, not just "it checks the type". Candidates who describe patterns as type tests alone usually go on to re-extract in the body.
That you know patterns nest, and can show a two-level pattern rather than a match inside a match.
That a wildcard binds nothing and is a statement about relevance, not a placeholder name.
That bindings are local to their case. This comes up the moment someone tries to use a name after the match.

None of this is about a particular syntax. Where languages differ is in the spelling and in how much of a value's structure is available to a pattern at all; what does not differ is the idea that the shape test and the names it produces are one construct.

## One construct, two jobs A **pattern** describes the shape a case is written for, and matching a value against it does two things in the same step. 1. It **tests**: does this value have that shape? A booking whose stay is a two-ended date range matches `Booking(guest, Range(start, end))`; a booking whose stay is open-ended does not. 2. It **binds**: every hole in the shape becomes a local name holding the part that filled it. Inside the case, `guest`, `start` and `end` are already in scope. That is the whole of what "destructuring in the pattern" means. The alternative - test the shape, then extract fields with accessors in the body - splits those two jobs apart, and every difference below follows from that split. ## Nesting reaches through a layer Patterns compose the way the data composes. A booking is a **product**: it holds a guest *and* a stay. A stay is a **sum**: it is *either* a two-ended range *or* an open-ended start. A nested pattern walks both in one expression. - `Booking(guest, Range(start, end))` matches a booking whose stay is a range, naming three parts at two different depths. - `Booking(_, OpenEnded(start))` matches the other stay shape and names only the start. - `Booking(guest, _)` matches any booking at all and names only the guest. The depth of the pattern is the depth of the reach. The body never has to hold the stay in a variable so it can ask it a second question, which is why a destructured case usually reads as one sentence about the one situation it handles. ## A wildcard is a part you are not asking about A **wildcard** matches whatever sits in its position and binds nothing. It is not a name: nothing in the body can read it. Two consequences are worth saying out loud. - It still occupies a **position**, so the pattern's shape is unchanged - `Booking(_, _)` is still a two-part booking, just one whose parts this case ignores. - Writing a wildcard rather than an unused name states the intent directly: this part does not participate in this case, so no reader goes hunting for where it is used. ## Scope of what a pattern binds The names a pattern binds belong to **that case only**. They come into existence when that case is selected and are not visible in the other cases or after the match finishes. Two cases may bind the same name from different positions without colliding, because they are different bindings in different scopes. This is why reading a destructured match is local work: the meaning of `start` is fixed by the one pattern directly above it. ## The body-side version, and what it costs | Concern | Bound in the pattern | Extracted in the body | |---|---|---| | Shape test | Part of the case; the case is chosen only if the shape fits | A separate condition the author must write and keep correct | | Naming the parts | Automatic, at the moment the test succeeds | Manual accessor calls after the test | | Nested shapes | One pattern reaches every depth | An intermediate value per layer, each usually re-tested | | When the shape does not fit | Control moves on to the next case | The author must remember to fall through or return | | Reading the code | The situation handled is visible on the case line | The situation is spread over the first few lines of the body | The practical failure of the body-side version is the third and fourth rows. Each extra layer adds a test the author can forget, and a test written by hand can disagree with the extraction that follows it - the shape is checked one way and taken apart another. A pattern cannot drift from itself, because the test and the extraction are the same piece of text. ## What an interviewer is listening for - That you say **both** jobs, not just "it checks the type". Candidates who describe patterns as type tests alone usually go on to re-extract in the body. - That you know patterns **nest**, and can show a two-level pattern rather than a match inside a match. - That a **wildcard binds nothing** and is a statement about relevance, not a placeholder name. - That bindings are **local to their case**. This comes up the moment someone tries to use a name after the match. None of this is about a particular syntax. Where languages differ is in the spelling and in how much of a value's structure is available to a pattern at all; what does not differ is the idea that the shape test and the names it produces are one construct.

What does a wildcard in a nested position of a pattern do?
It matches whatever occupies that position and binds no name, so the case is selected without the body gaining access to that part. `Booking(guest, Range(_, end))` handles any range, cares about the end date, and says plainly that the start is irrelevant here.
Are the names a pattern binds visible outside the case that bound them?
No. Each case's bindings live only in that case, so two cases can bind the same name from different positions without interfering, and nothing after the match can read either. That locality is why a reader can interpret a case from its own pattern line.
Is a pattern restricted to naming parts, or can it also demand specific values?
It can demand values too: a position may hold a constant instead of a name, so the case matches only when that part equals the constant. Naming a part and constraining it are the same mechanism at different strengths, which is why one pattern can express both.

A pattern is a cutting template laid over the value: if it fits, the pieces come out already labelled. Checking in the body is measuring the sheet first and then cutting freehand.

saying these in an interview costs you the question

Thinks a pattern only tests the shape and never binds anything
Re-checks in the branch body the shape the pattern already established
Believes patterns cannot nest, so every layer needs its own match
Treats a wildcard as a name the body can read later
Assumes a name bound in one case is visible in the other cases

In a match expression, what does binding a value's parts inside the pattern give you that reading fields in the branch body does not?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

One construct, two jobs

Nesting reaches through a layer

A wildcard is a part you are not asking about

Scope of what a pattern binds

The body-side version, and what it costs

What an interviewer is listening for

▾common follow-ups3 questions

▾analogy~10 s

▾red flags5 flags

One construct, two jobs

Nesting reaches through a layer

A wildcard is a part you are not asking about

Scope of what a pattern binds

The body-side version, and what it costs

What an interviewer is listening for

answer

go deeper