You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/rust.md
+25-21Lines changed: 25 additions & 21 deletions
Original file line number
Diff line number
Diff line change
@@ -2890,8 +2890,9 @@ match x {
2890
2890
2891
2891
The first pattern matches lists constructed by applying `Cons` to any head value, and a
2892
2892
tail value of `~Nil`. The second pattern matches _any_ list constructed with `Cons`,
2893
-
ignoring the values of its arguments. The difference between `_` and `*` is that the pattern `C(_)` is only type-correct if
2894
-
`C` has exactly one argument, while the pattern `C(..)` is type-correct for any enum variant `C`, regardless of how many arguments `C` has.
2893
+
ignoring the values of its arguments. The difference between `_` and `*` is that the pattern
2894
+
`C(_)` is only type-correct if `C` has exactly one argument, while the pattern `C(..)` is
2895
+
type-correct for any enum variant `C`, regardless of how many arguments `C` has.
2895
2896
2896
2897
A `match` behaves differently depending on whether or not the head expression
2897
2898
is an [lvalue or an rvalue](#lvalues-rvalues-and-temporaries).
@@ -2904,11 +2905,11 @@ variables in the arm's block, and control enters the block.
2904
2905
2905
2906
When the head expression is an lvalue, the match does not allocate a
2906
2907
temporary location (however, a by-value binding may copy or move from
2907
-
the lvalue). When possible, it is preferable to match on lvalues, as the
2908
+
the lvalue). When possible, it is preferable to match on lvalues, as the
2908
2909
lifetime of these matches inherits the lifetime of the lvalue, rather
2909
2910
than being restricted to the inside of the match.
2910
2911
2911
-
An example of an`match` expression:
2912
+
An example of a`match` expression:
2912
2913
2913
2914
~~~~
2914
2915
# fn process_pair(a: int, b: int) { }
@@ -2938,28 +2939,31 @@ Patterns that bind variables
2938
2939
default to binding to a copy or move of the matched value
2939
2940
(depending on the matched value's type).
2940
2941
This can be changed to bind to a reference by
2941
-
using the ```ref``` keyword,
2942
-
or to a mutable reference using ```ref mut```.
2942
+
using the `ref` keyword,
2943
+
or to a mutable reference using `ref mut`.
2943
2944
2944
-
Patterns can also dereference pointers by using the ``&``,
2945
-
``~`` or ``@`` symbols, as appropriate. For example, these two matches
2946
-
on ``x: &int`` are equivalent:
2945
+
Patterns can also dereference pointers by using the `&`,
2946
+
`~` or `@` symbols, as appropriate. For example, these two matches
2947
+
on `x: &int` are equivalent:
2947
2948
2948
2949
~~~~
2949
-
match *x { 0 => "zero", _ => "some" }
2950
-
match x { &0 => "zero", _ => "some" }
2950
+
# let x = &3;
2951
+
let y = match *x { 0 => "zero", _ => "some" };
2952
+
let z = match x { &0 => "zero", _ => "some" };
2953
+
2954
+
assert_eq!(y, z);
2951
2955
~~~~
2952
2956
2953
-
A pattern that's just an identifier,
2954
-
like `Nil` in the previous answer,
2955
-
could either refer to an enum variant that's in scope,
2956
-
or bind a new variable.
2957
-
The compiler resolves this ambiguity by forbidding variable bindings that occur in ```match``` patterns from shadowing names of variants that are in scope.
2958
-
For example, wherever ```List``` is in scope,
2959
-
a ```match``` pattern would not be able to bind ```Nil``` as a new name.
2960
-
The compiler interprets a variable pattern `x` as a binding _only_ if there is no variant named `x` in scope.
2961
-
A convention you can use to avoid conflicts is simply to name variants with upper-case letters,
2962
-
and local variables with lower-case letters.
2957
+
A pattern that's just an identifier, like `Nil` in the previous answer,
2958
+
could either refer to an enum variant that's in scope, or bind a new variable.
2959
+
The compiler resolves this ambiguity by forbidding variable bindings that occur
2960
+
in `match` patterns from shadowing names of variants that are in scope.
2961
+
For example, wherever `List` is in scope,
2962
+
a `match` pattern would not be able to bind `Nil` as a new name.
2963
+
The compiler interprets a variable pattern `x` as a binding _only_ if there is
2964
+
no variant named `x` in scope.
2965
+
A convention you can use to avoid conflicts is simply to name variants with
2966
+
upper-case letters, and local variables with lower-case letters.
2963
2967
2964
2968
Multiple match patterns may be joined with the `|` operator.
0 commit comments