Keyword match

Definition

match is a control-flow keyword that changes the program's execution path.

The keyword match structures execution. It determines when a block opens, when a branch is chosen, when a loop continues or stops, or when an exit becomes observable.

Grammatical role

Opens a pattern or variant analysis, distributing execution across multiple branch forms.

This grammatical role is essential: if a reader understands the structural place of match, they already understand much of the diagnostics that will appear when it is moved or truncated.

Canonical syntax

Canonical form: `match value { case ... }`.

The canonical form matters because it gives the compiler and the reader the same reference structure. A large share of diagnostics related to match come from an abbreviated, displaced, or incomplete form.

Detailed semantics

Semantically, match reorganizes the execution path. The right question is not only 'where is it placed?' but 'which path becomes possible, impossible, or preferred from this point onward?'

In an encyclopedic reading, match should not be reduced to a dictionary definition. Its effect on scope, block shape, value visibility, control progression, and the diagnostic family it activates when misused must also be considered.

Specific profile

Shape-analysis keyword. It expresses a decision governed by the structure of values, not merely by a sequence of boolean tests.

Design notes

• The strength of `match` is to make the space of expected forms explicit.
• Where `if` answers a boolean question, `match` answers a question about variants, patterns, or observable structure.

Reading questions

• Which value shapes are explicitly covered?
• Is the fallback branch intentional or merely defensive?
• Can the reader visually verify that the important cases are present?

Targeted anti-patterns

• Using `match` as a mere equality cascade without a clear structural benefit.
• Mixing responsibilities across branches so heavily that the pattern is no longer the real reading center.

Effect on execution

match immediately changes the execution path, whether by choosing a branch, repeating, interrupting, or terminating a flow.

In other words, the presence of match is not merely syntactic: it helps the reader predict what will be executed, produced, exposed, or forbidden from this point in the program.

Valid variants

• `match value { case ... }`
• `match value { case ... otherwise { ... } }`

These variants are not free synonyms. They indicate the legitimate forms from which one can reason about diagnostics, scope differences, or contract readability.

Vitte example

pick Resp {
  case Ok(value: int)
  case Err(code: int)
}

proc to_code(r: Resp) -> int {
  match r {
    case Ok(value) { give value }
    case Err(code) { give code }
    otherwise { give 70 }
  }
}

This example shows match in a nominal context. It should be read globally: where the contract begins, which values are constrained, which output becomes observable, and why the presence of the keyword is justified.

Guided reading of the example

1. First locate the full construction that contains match, not the isolated word.
2. Then identify which contract becomes visible because of match: type, branch, binding, module, exit, or advanced boundary.
3. Finish by checking the observable effect produced by the construction that contains match.
4. For a control keyword, mentally reconstruct the possible paths and the ones that become impossible.

This guided reading is intentionally closer to a reference page than to a tutorial: it helps reconstruct the exact role of match in a complete block.

Comparison with C

/* C comparison: this is usually expressed with enum tags plus switch/case. */

For this keyword, the parallel with C remains approximate. The comparison mainly indicates that in C the same idea is often spread across file conventions, operators, or less explicit control structures.

The source of truth remains Vitte grammar and semantics. The comparison with C should be read as a cultural marker, not as a parallel specification.

Recommended uses

match deserves to appear when it simplifies the reading of the block's global contract, not when it merely adds one more surface form.

When to use it

• When match makes the block contract more explicit at first reading.
• When it reduces the number of implicit assumptions the reader must reconstruct mentally.
• When a branch choice, repetition, or flow exit must be made visible.

When to avoid it

• Avoid match when another, more precise keyword already carries the block's intent.
• Avoid match when it adds only surface noise without clarifying the contract.
• Avoid reading or teaching it as an isolated token with no relation to the full structure.

Common pitfalls

• Using match in a grammatical layer where it does not belong.
• Confusing the role of the keyword with the role of the full surrounding block.
• Showing only the nominal form and never how the contract fails.

Invalid example and diagnostic

proc bad_match(r: int) -> int {
  match r
    case 0 { give 0 }
  }
}

The pattern surface is broken because the branch form is not structurally complete.

The counter-example is not merely wrong: it is wrong in an instructive way. It shows which grammar or execution-contract assumption is no longer accepted when match is moved, truncated, or combined with the wrong context. Concretely, the pattern-analysis structure is incomplete or badly closed.

A good encyclopedic counter-example does not show arbitrarily broken code: it isolates the precise reason why match can no longer support the expected contract. Its teaching value is diagnostic before it is syntactic.

Common compilation errors

This table does not replace the compiler's exact diagnostics. It serves as a mental map: when match fails, the problem usually comes from an invalid grammatical form, an incoherent type contract, or an incomplete construction.

Neighbor keywords

Comparison with neighboring keywords is essential on a wiki-style page: match is better understood when one knows precisely what it does not do.

Common misreadings

• Reading it as a repeated `if`, when the branching logic may be governed by variants or patterns instead.

Implementation and diagnostic notes

• Useful diagnostics for this family usually signal an incomplete branch shape, a mistyped condition, or an illegal placement in control flow.
• In a compiler, these keywords directly influence control-flow graph construction or intermediate representation building.

Presence in the book

• docs/book/chapters/07-control.html
• docs/book/chapters/27-grammar.html
• docs/book/chapters/31-build-errors.html

See also

• docs/book/chapters/keywords/erreurs-compilateur.html
• docs/book/chapters/keywords/if.html
• docs/book/glossary.html