Rust: Tracking issue for `#![feature(slice_patterns)]`

Created on 30 Jun 2019  路  16Comments  路  Source: rust-lang/rust

This is a tracking issue for the feature gate #![feature(slice_patterns)] covering the following RFCs:

  • "Finalize syntax for slice patterns with subslices" (rust-lang/rfcs#2359),
  • "Make .. a pattern syntactically" (rust-lang/rfcs#2707),
  • "Array pattern adjustments" (rust-lang/rfcs#495).

For the old tracking issue see https://github.com/rust-lang/rust/issues/23121.

Steps:

Unresolved questions:

None thus far.

A-slice-patterns B-RFC-approved B-RFC-implemented B-unstable C-tracking-issue F-slice_patterns T-lang

Most helpful comment

Subslice patterns were stabilized in https://github.com/rust-lang/rust/pull/67712.
Reference documentation is tracked in https://github.com/rust-lang/reference/issues/739.
Rustc-guide documentation is tracked in https://github.com/rust-lang/rustc-guide/issues/563.
Book documentation in the book is tracked in https://github.com/rust-lang/book/issues/2225.

All 16 comments

For now, I'm working on the syntactic aspect of supporting .. as a valid pattern syntactic pattern.

The syntax change in https://github.com/rust-lang/rfcs/pull/2707 was implemented on the 2019-07-28 in https://github.com/rust-lang/rust/pull/62550 (author: @Centril, reviewer: @petrochenkov).

What remains now is:

Before / during stabilization, we must also:

  • [x] Organize the tests.

Not sure either. Someone will have to make the call if it is okay for matching on big arrays to stack-overflow.

Last time I checked, on Windows, matching on [0u8; 1024] is actually enough to trigger the error.

https://github.com/rust-lang/rust/pull/63111 and https://github.com/rust-lang/rust/pull/63129 have both landed. In combination previously existing tests I believe we can be confident in the implementation now. The only remaining issue is https://github.com/rust-lang/rust/issues/53820 now.

@Centril would having an arbitrary size limit in arrays used in patterns help with masking #53820 to stabilize earlier?

@estebank Seems like bad policy to encode such arbitrary limits in the language itself? At minimum I want to know why it is the case that https://github.com/rust-lang/rust/issues/53820 happens and whether it is fundamental or a bug that we can fix soon-ish.

When this is stable, we should suggest using tail @ .. rather than ..tail, e.g. in:

fn foo(x: &[u32]) {
    match x {
        [..tail] => {} // error
    }
}

66502 is blocking this now.

* [ ]  One remaining issue is also #53820.
  cc RalfJung and varkor re. ^-- Not sure whether that's blocking or not.

Btw, #53820 is now fixed :)

66502 is now fixed, so I think there's nothing remaining blocking stabilisation.

There's #66934. I probably want to look at the tests that we have for slice patterns in const contexts once that's fixed.

We're definitely close to having something shippable, but before a report is ~written~ published (we can still prepare things for publishing), I think that we should:

We discussed this briefly in Thursday's language team meeting. I basically informed those present (only 3, including me) of ^--- and our almost-readiness for stabilization.

The stabilization PR and proposal is up in https://github.com/rust-lang/rust/pull/67712.

Subslice patterns were stabilized in https://github.com/rust-lang/rust/pull/67712.
Reference documentation is tracked in https://github.com/rust-lang/reference/issues/739.
Rustc-guide documentation is tracked in https://github.com/rust-lang/rustc-guide/issues/563.
Book documentation in the book is tracked in https://github.com/rust-lang/book/issues/2225.

Was this page helpful?
0 / 5 - 0 ratings