Pattern Matching

Pattern Matching


Destructuring extracts values from data structures using pattern matching. It makes code more concise and readable.

Array Destructuring

Test Coverage: ✅ tests/lang_comp/pattern_matching/destructuring.rs

Try It in the Notebook

Expected Output: 10

Tuple Destructuring

Expected Output: 10, 20

Nested Tuples

Expected Output: 1, 4

Object Destructuring

Expected Output: "Alice", 30

Renaming Fields

Expected Output: 1, "alice"

Struct Destructuring

Expected Output: 10.0

Enum Destructuring

Expected Output: "Moving to (10, 20)"

Ignoring Values

Underscore Pattern

Expected Output: 1, 3

Rest Pattern

Expected Output: 1, [2, 3, 4, 5]

Function Parameters

Expected Output: Point at (10, 20)

Tuple Parameters

Expected Output: 5.0

For Loop Destructuring

Expected Output: (1, 2), (3, 4), (5, 6)

Object Iteration

Expected Output: Alice is 30 years old, Bob is 25 years old

Nested Destructuring

Expected Output: "Alice", "alice@example.com"

Common Patterns

Swap Variables

Expected Output: 20, 10

Extract First and Last

Expected Output: (1, 5)

Parse Coordinates

Expected Output: (10, 20)

Config Extraction

Expected Output: "http://example.com:80"

Default Values

Expected Output: "Hello Alice, age 0", "Hello Guest, age 0"

Option Destructuring

Expected Output: "Got 42"

If Let

Expected Output: Value: 42

Result Destructuring

Expected Output: "Result: 5"

Best Practices

✅ Use Destructuring for Clarity

✅ Ignore Unused Values

✅ Destructure in Function Parameters

✅ Use Defaults for Optional Fields

Destructuring vs Manual Access

Method Code Readability Use Case
Destructuring let { x, y } = point High Multiple fields
Manual Access let x = point.x Medium Single field

Summary

Feature Status: WORKING
Test Coverage: 100%
Mutation Score: 97%

Destructuring extracts values from data structures in a concise, readable way. It works with arrays, tuples, objects, structs, and enums.

Key Takeaways:

  • Arrays: let [a, b, c] = arr
  • Tuples: let (x, y) = tuple
  • Objects: let { name, age } = obj
  • Ignore with _ or ...rest
  • Works in function parameters and for loops
  • Use defaults for optional values

← Previous: Enums | Next: Pattern Guards →


Pattern guards add conditional logic to pattern matching using if expressions. They enable more precise pattern matching beyond structural patterns alone.

Basic Guards

Test Coverage: ✅ tests/lang_comp/pattern_matching/guards.rs

Try It in the Notebook

Expected Output: "Adult"

Guards with Destructuring

Expected Output: "Below diagonal"

Enum Guards

Expected Output: "High priority task 1"

Common Patterns

Range Checking

Expected Output: "B"

Validation

Expected Output: Ok({ age: 25, name: "Alice" })

Complex Conditions

Expected Output: "Ascending order"

Option Guards

Expected Output: "Value: 42"

Result Guards

Expected Output: "Success: 42"

Multiple Guards

Expected Output: "Ascending"

Guards vs Nested If

With Guards (Good)

Nested If (Bad)

Best Practices

✅ Use Guards for Value Checks

✅ Keep Guards Simple

✅ Order Guards Carefully

Summary

Feature Status: WORKING
Test Coverage: 100%
Mutation Score: 96%

Pattern guards add conditional logic to match expressions using if, enabling precise pattern matching beyond structural patterns.

Key Takeaways:

  • Syntax: pattern if condition => result
  • Works with all pattern types
  • Guards evaluated after pattern matches
  • Keep guards simple and readable
  • Order guards from specific to generic
  • Prefer guards over nested if statements

← Previous: Destructuring | Next: Exhaustiveness →


Exhaustiveness checking ensures that match expressions handle all possible cases. The compiler verifies that no case is missed, preventing runtime errors.

Why Exhaustiveness Matters

Test Coverage: ✅ tests/lang_comp/pattern_matching/exhaustiveness.rs

Wildcard Pattern

Use _ to catch all remaining cases:

Expected Output: Exhaustive with wildcard

Option Exhaustiveness

Expected Output: Both patterns are exhaustive

Result Exhaustiveness

Expected Output: Exhaustive error handling

Tuple Exhaustiveness

Expected Output: All boolean combinations handled

Common Patterns

Catch-All Pattern

Expected Output: Handles all possible integers

Named Catch-All

Expected Output: Can use the unmatched value

Ignoring Values

Expected Output: Exhaustive without binding values

Nested Exhaustiveness

Expected Output: All nested cases handled

Best Practices

✅ Handle All Cases Explicitly

✅ Use Wildcards Wisely

✅ Be Explicit When Adding Variants

Summary

Feature Status: WORKING
Test Coverage: 100%
Mutation Score: 98%

Exhaustiveness checking ensures all cases are handled in match expressions, preventing runtime errors and enforcing complete case coverage at compile time.

Key Takeaways:

  • Compiler verifies all patterns are covered
  • Use _ for catch-all patterns
  • Named wildcards when you need the value
  • Be explicit about important cases
  • Wildcards can hide bugs when enum variants are added
  • Exhaustiveness works with Option, Result, enums, tuples

← Previous: Pattern Guards | Next: Error Handling →