Simplify rules for GenericArgs nonterminal and other small improvements and fixes #805
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -20,7 +20,7 @@ x::y::z; | ||
|
|
||
| > **<sup>Syntax</sup>**\ | ||
| > _SimplePath_ :\ | ||
| > `::`<sup>?</sup> _SimplePathSegment_ ( `::` _SimplePathSegment_ )<sup>\*</sup> | ||
| > | ||
| > _SimplePathSegment_ :\ | ||
| > [IDENTIFIER] | `super` | `self` | `crate` | `$crate` | ||
| @@ -40,42 +40,34 @@ mod m { | ||
|
|
||
| > **<sup>Syntax</sup>**\ | ||
| > _PathInExpression_ :\ | ||
| > `::`<sup>?</sup> _PathExprSegment_ ( `::` _PathExprSegment_ )<sup>\*</sup> | ||
| > | ||
| > _PathExprSegment_ :\ | ||
| > _PathIdentSegment_ ( `::` `<` _GenericArguments_<sup>?</sup> `>` )<sup>?</sup> | ||
| > | ||
| > _PathIdentSegment_ :\ | ||
| > [IDENTIFIER] | `super` | `self` | `Self` | `crate` | `$crate` | ||
| > | ||
| > _GenericArguments_ :\ | ||
| > _GenericArgument_ ( `,` _GenericArgument_ )<sup>\*</sup> `,`<sup>?</sup> | ||
| > | ||
| > _GenericArgument_ :\ | ||
| > [_Lifetime_]\ | ||
| > | [_Type_]\ | ||
| > | [IDENTIFIER] `=` [_Type_] | ||
| Paths in expressions allow for paths with generic arguments to be specified. They are | ||
| used in various places in [expressions] and [patterns]. | ||
|
|
||
| The `::` token is required before the opening `<` for generic arguments to avoid | ||
| ambiguity with the less-than operator. This is colloquially known as "turbofish" syntax. | ||
|
|
||
| Generic arguments are passed in the order that they're declared in. In particular, | ||
| lifetime arguments must come before type arguments. The last kind of argument, | ||
| `Ident = Type`, is for specifying [associated types] in [trait bounds]. | ||
| These arguments are not positional (i.e. their order does not matter), and they | ||
| must come after all the other (positional) arguments. | ||
|
Comment on lines
+65
to
+69
There was a problem hiding this comment. The first sentence seems to be immediately contradicted by the statement that the order of bindings doesn't matter. Perhaps it would help to explicitly name the 3 argument kinds, specify the order they must appear in relation to each other, and then delve into the specifics of how type bindings work? I'd also lean towards retaining the named nonterminals in the grammar, so there is something to refer to (like GenericArgsBinding). I'm also a little amused about the idea of specifying how the order of arguments correlates to the parameters. Most specs I've read just ignore this, presumably assuming everyone knows function arguments are passed in the given order to the corresponding parameters. There was a problem hiding this comment. The main point was that if you already know that the argument order matches the declaration, then the fact that lifetime argument come before type arguments directly follows from the fact that function, trait and method declarations must put lifetime arguments first. I’ll try to get rid of the contradictory statements, and reintroducing (at least some of) the names seems like a very good idea to make things clearer. There was a problem hiding this comment.
The compiler seems to (maybe) apply the same logic (note how it only complains about “associated type bindings” coming before “generic parameters” without knowing the details Well, it can also generate weird messages if you do let it know of a |
||
|
|
||
| ```rust | ||
| (0..10).collect::<Vec<_>>(); | ||
| Vec::<u8>::with_capacity(1024); | ||
| @@ -85,13 +77,13 @@ Vec::<u8>::with_capacity(1024); | ||
|
|
||
| > **<sup>Syntax</sup>**\ | ||
| > _QualifiedPathInExpression_ :\ | ||
| > _QualifiedPathType_ ( `::` _PathExprSegment_ )<sup>+</sup> | ||
| > | ||
| > _QualifiedPathType_ :\ | ||
| > `<` [_Type_] ( `as` _TypePath_ )<sup>?</sup> `>` | ||
| > | ||
| > _QualifiedPathInType_ :\ | ||
| > _QualifiedPathType_ ( `::` _TypePathSegment_ )<sup>+</sup> | ||
| Fully qualified paths allow for disambiguating the path for [trait implementations] and | ||
| for specifying [canonical paths](#canonical-paths). When used in a type specification, it | ||
| @@ -119,13 +111,14 @@ S::f(); // Calls the inherent impl. | ||
|
|
||
| > **<sup>Syntax</sup>**\ | ||
| > _TypePath_ :\ | ||
| > `::`<sup>?</sup> _TypePathSegment_ ( `::` _TypePathSegment_ )<sup>\*</sup> | ||
| > | ||
| > _TypePathSegment_ :\ | ||
| > _PathIdentSegment_ ( `::`<sup>?</sup> _TypePathArguments_ )<sup>?</sup> | ||
| > | ||
| > _TypePathArguments_ :\ | ||
| > `<` [_GenericArguments_]<sup>?</sup> `>`\ | ||
| > | `(` _TypePathFnInputs_<sup>?</sup> `)` [_FunctionReturnType_]<sup>?</sup> | ||
| > | ||
| > _TypePathFnInputs_ :\ | ||
| > [_Type_] (`,` [_Type_])<sup>\*</sup> `,`<sup>?</sup> | ||
| @@ -364,9 +357,10 @@ mod without { // ::without | ||
| # fn main() {} | ||
| ``` | ||
|
|
||
| [_GenericArguments_]: #paths-in-expressions | ||
| [_Lifetime_]: trait-bounds.md | ||
| [_Type_]: types.md#type-expressions | ||
| [_FunctionReturnType_]: items/functions.md | ||
| [item]: items.md | ||
| [variable]: variables.md | ||
| [implementations]: items/implementations.md | ||
| @@ -381,3 +375,5 @@ mod without { // ::without | ||
| [trait implementations]: items/implementations.md#trait-implementations | ||
| [traits]: items/traits.md | ||
| [visibility]: visibility-and-privacy.md | ||
| [associated types]: items/associated-items.md#associated-types | ||
| [trait bounds]: trait-bounds.md | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You've removed LifetimeParams, so either this will need to be updated, or LifetimeParams will need to be added back.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah... missed that – good thing I changed them both in an earlier commit in a way that required updating all uses and hence the uses pop out in the diff.