Stabilize "RangeFrom" patterns in 1.55 by workingjubilee · Pull Request #83918 · rust-lang/rust (original) (raw)

I'm sorry, I don't know if I truly understand what you actually mean here. ".. excepting RangeFull" seems like a contradiction. I currently assume you mean the slicing patterns that match the RangeFrom, RangeTo, and RangeExclusive patterns, but I am not sure, because when I first read it yesterday, I assumed you meant literally barring the .. token except for the specific character sequence of [..] only. Which would clearly be unacceptable, because I regularly use patterns akin to this:

let xs = [13, 1, 5, 2, 3, 1, 21, 8]; let [a, b, c @ ..] = xs; println!(r"first element: {a} second element: {b} rest: {c:?}", a = a, b = b, c = c);

Specifically I like this for repeatedly dismantling parts of a slice for e.g. argument parsing. Which is valid with or without the @ binding and capturing .. and its associated values here. Now, at this point I am more confident that I am repeating you, as I believe you're looking at the case of a slice pattern combining with a RangeFrom and RangeTo pattern, and how it would be desirable to instead have

let [first_two @ ..2, rest @ 2..] = xs;

work on multi-element arrays, whereas instead it errors with

error[E0527]: pattern requires 2 elements but array has 8
 --> src/main.rs:6:5
  |
6 | let [first_two @ ..2, rest @ 2..] = xs;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected 8 elements

error: aborting due to previous error

However, this currently already works,

// The pattern becomes refutable because this is now matching on an integer inside the slice pattern. if let [a, b, c @ 5..=9, ..] = xs { println!("captured {}, {}, and {}!", a, b, c); // prints: captured 13, 1, and 5! } else { println!("whoops"); }

So, my response is: I believe the ship may have actually sailed already for RangeExclusive patterns, because they should match RangeInclusive patterns in basically all ways excepting the range inclusiveness. I believe allowing "slicing RangeTo" and "slicing RangeFrom" patterns is plausible, but is conditioned on our accepting the deviance of RangeFrom and RangeTo vs. RangeInclusive/RangeExclusive, or doing an appropriate "edition dance". I indeed could see barring RangeExclusive, RangeFrom, and RangeTo within slice patterns for the moment and advancing an RFC which addresses this fully.

I believe the RangeFrom patterns are noncontroversial outside slice patterns, because validating it in the simple non-slicing cases won't introduce more confusion. And there's already some notional overlap in slice patterns with legal SliceIndex expressions. I repeat myself, but again, this is valid:

println!("{:?}", &xs[2..=5]); // prints: [5, 2, 3, 1]

but "conflicts" with the slice pattern

let [ys @ 2..=5] = xs; println!("{:?}", ys);

instead producing the error

error[E0527]: pattern requires 1 element but array has 8
 --> src/main.rs:6:5
  |
6 | let [ys @ 2..=5] = xs;
  |     ^^^^^^^^^^^^ expected 8 elements