Skip to content

Latest commit

 

History

History
96 lines (69 loc) · 2.89 KB

2707-dotdot-patterns.md

File metadata and controls

96 lines (69 loc) · 2.89 KB
Raw

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.

  • 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
  • Some nonsensical code can now be accepted under 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

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

  • Immediately inside a tuple struct/variant pattern Tuple(PAT, .., PAT)
  • Immediately inside a tuple pattern (PAT, .., PAT)
  • Immediately inside a slice pattern [PAT, .., PAT].
  • Immediately inside a binding pattern inside a slice pattern [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.

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 #2359.

Unresolved questions

None so far.

Future possibilities

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