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

[nikomatsakis]

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

History and status

• Implemented in #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.

[ghost]

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.

[aturon]

triage: I-nominated ()

[pnkfelix]

P-high, not 1.0.

[aturon]

I've repurposed this as a general tracking issue for the slice_patterns and advanced_slice_patterns features.

[petrochenkov]

Syntax for named subslice a.. conflicts with potential future exclusive slice patterns. Either it should be changed, or exclusive slice patterns should be forever rejected, or something else.

[nikomatsakis]

So, once MIR is around, I'll feel much better about this feature from the POV of soundness. It's certainly convenient once in a while. But I have realized a few quirks recently:

1. I think there is still some debate about whether [] patterns should match &[T] values. I think no, you should write the &.
2. I don't think that there is a syntax for taking a mut subslice.
3. The syntax conflicts with exclusive slice patterns (as @petrochenkov pointed out).
4. It's a bit unclear to me if the slice part is intended as a fresh subpattern. Seems like it should be.

[petrochenkov]

It would be also nice to have unnamed .. or even named sub.. sublists in tuple and especially tuple variant patterns, but whatever syntax choice is made for slices it probably can be reused there.

I don't think that there is a syntax for taking a mut subslice.

[a, ref mut b..] seems to compile, its just not have been updated to by-value semantics from rust-lang/rfcs#495. Subslice is an arbitrary pattern after all.

[nikomatsakis]

On Thu, Nov 05, 2015 at 12:02:03PM -0800, Vadim Petrochenkov wrote:

I don't think that there is a syntax for taking a mut subslice.

[a, ref mut b..] seems to compile, its just not have been updated to by-value semantics from rust-lang/rfcs#495. Subslice is an arbitrary pattern after all.

I would expect that to produce a &mut &[T] value. Is that not what it does? (In particular, the ref isn't normally required to get a value of type &[T], is it?)

[jethrogb]

I just want matching against constant fixed-length arrays. The .. stuff you can already do with split_at.

[nikomatsakis]

I agree with @jethrogb in that it would be amazing if we could move towards stabilising the simple, unambiguous cases for fixed-size arrays first.

I could get behind this plan (i.e., no .. at all).

[SoniEx2]

Why not x @ ..?

If you have something like [ref mut a, x @ .., ref mut b], what's wrong with having a mutable ref to a, a mutable ref to b, and a mutable slice x that doesn't include a or b? The aliasing still holds up, no?

Edit: Oh I see, I should've read the full thing.

Why not remove the .. entirely?

[a, @, b] if you don't want the thing, [a, x@, b] to capture the thing?

(Not sure if this has been suggested)

[petrochenkov]

#34708 was fixed by @mikhail-m1.
Any other codegen bugs blocking stabilization?

[nikomatsakis]

@petrochenkov of what specific subset?

If you want to stabilize, can you please open up a new issue that describes the behavior we are stabilizing, giving examples of tests that show how it works? It would be great to also specify what is not being stabilized. Example: #48453

I don't know if there are other bugs, I know that @mikhail-m1 has been working on improving various double-drop bugs and analysis, but I think more for slice patterns.

[mikhail-m1]

my view of current state

item	state
The syntax conflicts with exclusive range patterns.	completed
#8636 Matches on &mut[] move the .. match & don't consider disjointness	I will look, need to check is nested cases support needed
#26736 cannot move into irrefutable slice patterns with multiple elements	bug only in AST borrowck
#34708 double drop with slice patterns	fixed
#26619 (Only E-needstest) Yet another bug with slice_patterns	doesn't relate
#23311 (Only E-needstest) LLVM Assertion: Both operands to ICmp instruction are not of the same type!	marked done

[petrochenkov]

Excellent, looks like there are no codegen issues and no issues that may require breaking backward compatibility in the future.

In this case I'll prepare a stabilization PR for slice patterns without .., and a mini-RFC attempting to finalize syntax for slice patterns with ...

[nikomatsakis]

I just proposed stabilizing the subset without .. patterns in this issue:

#48836

[petrochenkov]

"Mini-RFC: Finalize syntax for slice patterns with subslices"

[abonander]

@petrochenkov Given the mutual impls of PartialEq for String and &str, I expected this to work: https://play.rust-lang.org/?gist=8157ad5c25d456007b27e3b62b8ce866&version=beta

It seems too strict to require the pattern to have the same element type as the matched slice.

[petrochenkov]

@abonander
This looks more like some extension to #42640 using Deref rather than something specific to slice patterns.

[samuela]

Any update on this? Being able to pattern match against Vecs and arrays is hugely important for many people coming from functional languages.

[jethrogb]

Rust has had basic slice patterns since 1.26. More advanced patterns are being discussed in rust-lang/rfcs#2359.

[samuela]

@jethrogb Ah gotcha, what's the current recommended approach to destruct a Vec into head/tail?

[jethrogb]

[T]::split_at might work for you, depending on your usecase.

[samuela]

@jethrogb Ok, thanks. I'm hoping to be able to match against [] vs x :: xs in one fell swoop, but split_at with an if would technically work.

[cuviper]

You can match on split_first() for that.