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
In actuality, the parser is going to treat an inferred const as an
inferred type, so we don't need a separate rule for this, and removing
this rule avoids some ambiguity in our grammar. We'll add a note
describing this situation.
Copy file name to clipboardExpand all lines: src/items/generics.md
+3-3Lines changed: 3 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -172,12 +172,12 @@ fn example() {
172
172
```
173
173
174
174
r[items.generics.const.inferred]
175
-
Where a const argument is expected, an `_` (optionally surrounding by any number of matching parentheses), called the *inferred const* ([grammar][InferredConst], [path rules][paths.expr.complex-const-params]), can be used instead. This asks the compiler to infer the const argument if possible based on surrounding information.
175
+
Where a const argument is expected, an `_` (optionally surrounding by any number of matching parentheses), called the *inferred const* ([path rules][paths.expr.complex-const-params]), can be used instead. This asks the compiler to infer the const argument if possible based on surrounding information.
0 commit comments