Patterns
Syntax
Pattern :
PatternWithoutRange
| RangePatternSyntax
Pattern :
|? PatternNoTopAlt (|PatternNoTopAlt )*PatternNoTopAlt :
PatternWithoutRange
| RangePatternPatternWithoutRange :
LiteralPattern
| IdentifierPattern
| WildcardPattern
| RestPattern
| ObsoleteRangePattern
| ReferencePattern
| StructPattern
| TupleStructPattern
| TuplePattern
| GroupedPattern
| SlicePattern
| PathPattern
| MacroInvocation
Patterns are used to match values against structures and to, optionally, bind variables to values inside these structures. They are also used in variable declarations and parameters for functions and closures.
Path patterns are irrefutable when they refer to structs or an enum variant when the enum has only one variant or a constant whose type is irrefutable. They are refutable when they refer to refutable constants or enum variants for enums with multiple variants.
Or-patterns
Or-patterns are patterns that match on one of two or more sub-patterns (e.g. A | B | C). They can nest arbitrarily. Syntactically, or-patterns are allowed in any of the places where other patterns are allowed (represented by the Pattern production), with the exceptions of let-bindings and function and closure arguments (represented by the PatternNoTopAlt production).
Static semantics
-
Given a pattern
p | qat some depth for some arbitrary patternspandq, the pattern is considered ill-formed if:- the type inferred for
pdoes not unify with the type inferred forq, or - the same set of bindings are not introduced in
pandq, or - the type of any two bindings with the same name in
pandqdo not unify with respect to types or binding modes.
Unification of types is in all instances aforementioned exact and implicit type coercions do not apply.
- the type inferred for
-
When type checking an expression
match e_s { a_1 => e_1, ... a_n => e_n }, for each match arma_iwhich contains a pattern of formp_i | q_i, the patternp_i | q_iis considered ill formed if, at the depthdwhere it exists the fragment ofe_sat depthd, the type of the expression fragment does not unify withp_i | q_i. -
With respect to exhaustiveness checking, a pattern
p | qis considered to coverpas well asq. For some constructorc(x, ..)the distributive law applies such thatc(p | q, ..rest)covers the same set of value asc(p, ..rest) | c(q, ..rest)does. This can be applied recursively until there are no more nested patterns of formp | qother than those that exist at the top level.Note that by "constructor" we do not refer to tuple struct patterns, but rather we refer to a pattern for any product type. This includes enum variants, tuple structs, structs with named fields, arrays, tuples, and slices.
Dynamic semantics
- The dynamic semantics of pattern matching a scrutinee expression
e_sagainst a patternc(p | q, ..rest)at depthdwherecis some constructor,pandqare arbitrary patterns, andrestis optionally any remaining potential factors inc, is defined as being the same as that ofc(p, ..rest) | c(q, ..rest).
Precedence with other undelimited patterns
As shown elsewhere in this chapter, there are several types of patterns that are syntactically undelimited, including identifier patterns, reference patterns, and or-patterns. Or-patterns always have the lowest-precedence. This allows us to reserve syntactic space for a possible future type ascription feature and also to reduce ambiguity. For example, x @ A(..) | B(..) will result in an error that x is not bound in all patterns, &A(x) | B(x) will result in a type mismatch between x in the different subpatterns.
Uh oh!
There was an error while loading. Please reload this page.