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