RFC 2707: Make .. a proper pattern

lang (syntax | patterns)

Summary

Make .. a pattern rather than a syntactic fragment of some other patterns.

Motivation

The change simplifies pattern grammar and simplifies use of .. in macros.
In particular, the pat macro matcher will now accept .. and IDENT @ ...

Guide-level explanation

.. becomes a pattern syntactically. The notable consequences of this are listed below.

Variant(a, b, ..,) // OK
#[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

Reference-level explanation

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

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.

Drawbacks

More meaningless code may be accepted under cfg(FALSE) where semantic checks are not performed.

Rationale and alternatives

See "Motivation" for the rationale.
Status quo is always an alternative.

Prior art

This RFC is a follow up to https://github.com/rust-lang/rfcs/pull/2359.

Unresolved questions

None so far.

Future possibilities

Accept BINDING @ .. in tuple patterns, (head, tail @ ..).