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
//the user doesn't have enough credit, return an error message
45
+
//The user doesn't have enough credit, return an error message.
46
46
}
47
47
}
48
48
```
@@ -109,7 +109,7 @@ let x if guard(x) = foo() {}
109
109
ifletxifguard(x) =foo() {}
110
110
whileletxifguard(x) =foo() {}
111
111
112
-
//allowed
112
+
//Allowed:
113
113
let (xifguard(x)) =foo() {} // Note that this would still error after parsing, since guard patterns are always refutable.
114
114
iflet (xifguard(x)) =foo() {}
115
115
whilelet (xifguard(x)) =foo() {}
@@ -181,7 +181,7 @@ Earlier it was mentioned that guards can "move outwards" up to an or-pattern wit
181
181
(Ok(Ok(xifx>0))) | (Err(Err(xifx<0)))
182
182
<=> (Ok(Ok(x) ifx>0)) | (Err(Err(x) ifx<0))
183
183
<=> (Ok(Ok(x)) ifx>0) | (Err(Err(x)) ifx<0)
184
-
//cannot move outwards any further, because the conditions are different
184
+
//Cannot move outwards any further, because the conditions are different.
185
185
```
186
186
187
187
In most situations, it is preferable to have the guard as far outwards as possible; that is, at the top-level of the whole pattern or immediately within one alternative of an or-pattern.
0 commit comments