lang (syntax | patterns)
dotdot_patterns
Make ..
a pattern rather than a syntactic fragment of some other patterns.
The change simplifies pattern grammar and simplifies use of ..
in macros.
In particular, the pat
macro matcher will now accept ..
and IDENT @ ..
.
..
becomes a pattern syntactically.
The notable consequences of this are listed below.
pat
macro matcher will now accept ..
and more complex pattern containing ..
,
for example ref x @ ..
.
A trailing comma is accepted after ..
in tuple struct, tuple or slice pattern.
Variant(a, b, ..,) // OK
cfg(FALSE)
.#[cfg(FALSE)]
Tuple(.., a, ..) // OK
..
in "inappropriate" positions is still rejected semantically.
let .. = 10; // Semantic error, `..` is not a part of a "list" pattern
let Option(.., ..) = 11; // Semantic error, multiple `..`s in a single "list" pattern
Pattern grammar is extended with a new production
PAT = ..
Special productions allowing ..
in tuple struct, tuple and slice patterns are subsumed by this
new production and removed.
Semantically, the ..
pattern is accepted
Tuple(PAT, .., PAT)
(PAT, .., PAT)
[PAT, .., PAT]
.[PAT, BINDING @ .., PAT]
.An error is produced if this pattern is used in any other position.
An error is produced if more that one ..
or BINDING @ ..
pattern is used inside its containing
tuple struct / tuple / slice pattern.
(..)
is still a tuple pattern and not a parenthesized ..
pattern for backward compatibility.
Note that ..
in struct patterns
Struct { field1: PAT, field2, .. }
is still not a pattern, but a fragment of a struct pattern syntax.
More meaningless code may be accepted under cfg(FALSE)
where semantic checks are not performed.
See "Motivation" for the rationale.
Status quo is always an alternative.
This RFC is a follow up to https://github.com/rust-lang/rfcs/pull/2359.
None so far.
Accept BINDING @ ..
in tuple patterns, (head, tail @ ..)
.