Tracking issue for RFC #495 (features `slice_patterns` and `advanced_slice_patterns`)

[nikomatsakis]

New tracking issue: #62254

Old content

Tracking issue for rust-lang/rfcs#495

Breaking Changes

This RFC is a breaking change for most users of slice patterns. The main change is that slice patterns now have the type [_] instead of &[_].

For example, in the old semantics

fn slice_pat(x: &[u8]) {
    // OLD!
    match x {
        [a, b..] => {}
    }
}

the [a, b..] would have the type &[u8], a would have the type u8 and b the type &[u8].

With the new semantics, [a, b..] would have the type [u8] and b the type [u8] - which are the wrong types. To fix that, add a & before the slice and a ref before the tail as if you were matching a struct (of course, use ref mut if you want a mutable reference):

fn slice_pat(x: &[u8]) {
    // NEW
    match x {
        &[a, ref b..] => {}
    }
}

Concerns to be resolved before stabilization

• The syntax conflicts with exclusive range patterns.
• Matches on &mut[] move the .. match & don't consider disjointness #8636 Matches on &mut[] move the .. match & don't consider disjointness
• cannot move into irrefutable slice patterns with multiple elements #26736 cannot move into irrefutable slice patterns with multiple elements
• [MIR] double drop with slice patterns #34708 double drop with slice patterns
• Yet another bug with slice_patterns #26619 (Only E-needstest) Yet another bug with slice_patterns
• LLVM Assertion: Both operands to ICmp instruction are not of the same type! #23311 (Only E-needstest) LLVM Assertion: Both operands to ICmp instruction are not of the same type!

History and status

• Implemented in Implement RFC495 semantics for slice patterns #32202
• Still needs better integration with MIR borrowck to resolve soundness concerns, I believe

[nikomatsakis]

triage: P-backcompat-lang (1.0 beta) -- at least for the backwards incompatible parts of rust-lang/rfcs#495. This is something of a nice to have, we can live with it if it doesn't get done.

I'm on it, by the way.

https://github.com/jakub-/rust/tree/array-pattern-changes. I'll open a PR soon.

[nikomatsakis]

@jakub- go go go!

[nikomatsakis]

🐎

[pnkfelix]

(this is puntable to 1.0 if necessary, but we hope to have it by 1.0 beta.)

[pnkfelix]

We are going to feature-gate array patterns, in order to ensure that we can soundly land these changes to the semantics in the future.

[aturon]

Moving off of milestone, since these are now gated.