Stabilize "RangeFrom" patterns in 1.55

[workingjubilee]

Implements a partial stabilization of #67264 and #37854.
Reference PR: rust-lang/reference#900

Stabilization Report

This stabilizes the X.. pattern, shown as such, offering an exhaustive match for unsigned integers:

match x as u32 {
      0 => println!("zero!"),
      1.. => println!("positive number!"),
}

Currently if a Rust author wants to write such a match on an integer, they must use 1..={integer}::MAX . By allowing a "RangeFrom" style pattern, this simplifies the match to not require the MAX path and thus not require specifically repeating the type inside the match, allowing for easier refactoring. This is particularly useful for instances like the above case, where different behavior on "0" vs. "1 or any positive number" is desired, and the actual MAX is unimportant.

Notably, this excepts slice patterns which include half-open ranges from stabilization, as the wisdom of those is still subject to some debate.

Practical Applications

Instances of this specific usage have appeared in the compiler:

rust/compiler/rustc_middle/src/ty/inhabitedness/mod.rs

Line 219 in 16143d1

Some(1..) => ty.uninhabited_from(tcx, param_env),

rust/compiler/rustc_ty_utils/src/ty.rs

Line 524 in 673d0db

Some(1..) => tcx.conservative_is_privately_uninhabited(param_env.and(ty)),

And I have noticed there are also a handful of "in the wild" users who have deployed it to similar effect, especially in the case of rejecting any value of a certain number or greater. It simply makes it much more ergonomic to write an irrefutable match, as done in Katholieke Universiteit Leuven's SCALE and MAMBA project.

Tests

There were already many tests in src/test/ui/half-open-range/patterns, as well as generic pattern tests that test the exclusive_range_pattern feature, many dating back to the feature's introduction and remaining standing to this day. However, this stabilization comes with some additional tests to explore the... sometimes interesting behavior of interactions with other patterns. e.g. There is, at least, a mild diagnostic improvement in some edge cases, because before now, the pattern 0..=(5+1) encounters the half_open_range_patterns feature gate and can thus emit the request to enable the feature flag, while also emitting the "inclusive range with no end" diagnostic. There is no intent to allow an X..= pattern that I am aware of, so removing the flag request is a strict improvement. The arrival of the J | K "or" pattern also enables some odd formations.

Some of the behavior tested for here is derived from experiments in this Playground example, linked at #67264 (comment), which may be useful to reference to observe the current behavior more closely.

In addition tests constituting an explanation of the "slicing range patterns" syntax issue are included in this PR.

Desiderata

The exclusive range patterns and half-open range patterns are fairly strongly requested by many authors, as they make some patterns much more natural to write, but there is disagreement regarding the "closed" exclusive range pattern or the "RangeTo" pattern, especially where it creates "off by one" gaps in the presence of a "catch-all" wildcard case. Also, there are obviously no range analyses in place that will force diagnostics for e.g. highly overlapping matches. I believe these should be warned on, ideally, and I think it would be reasonable to consider such a blocker to stabilizing this feature, but there is no technical issue with the feature as-is from the purely syntactic perspective as such overlapping or missed matches can already be generated today with such a catch-all case. And part of the "point" of the feature, at least from my view, is to make it easier to omit wildcard matches: a pattern with such an "open" match produces an irrefutable match and does not need the wild card case, making it easier to benefit from exhaustiveness checking.

History

• Implemented:
  • Partially via exclusive ranges: exclusive range patterns #35712
  • Fully with half-open ranges: Introduce X.., ..X, and ..=X range patterns #67258
• Unresolved Questions:
  • The precedence concerns of Operators in patterns have incorrect priorities #48501 were considered as likely requiring adjustment but probably wanting a uniform consistent change across all pattern styles, given Tracking issue for ..X, and ..=X (#![feature(half_open_range_patterns)]) #67264 (comment), but it is still unknown what changes might be desired
  • How we want to handle slice patterns in ranges seems to be an open question still, as witnessed in the discussion of this PR!

I checked but I couldn't actually find an RFC for this, and given "approved provisionally by lang team without an RFC", I believe this might require an RFC before it can land? Unsure of procedure here, on account of this being stabilizing a subset of a feature of syntax.

r? @scottmcm

[scottmcm]

Lang previously expressed interest in stabilizing this, so let's do it!

I think this is a particularly nice win when coupled with the exhaustive integer matching from 1.33, as a great way to write "and everything X and above" without using a wildcard.

@rfcbot fcp merge

[rfcbot]

Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:

• @cramertj
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm

Concerns:

• consider-alternative-further resolved by Stabilize "RangeFrom" patterns in 1.55 #83918 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[nikomatsakis]

@rfcbot reviewed

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[bstrie]

This has a little bit of a surprising contrast with slice patterns. Consider this (working) code:

let x = [-100, -50, 50, 100];

assert_eq!(&x[..], &[-100, -50, 50, 100]);
assert_eq!(&x[..2], &[-100, -50]);
assert_eq!(&x[2..], &[50, 100]);
assert_eq!(&x[1..3], &[-50, 50]);

let [y @ ..] = x;
assert_eq!(x, y);

A user might then expect the following to work:

let [neg @ ..2, pos @ 2..] = x; // error
assert_eq!(neg, [-100, -50]);
assert_eq!(pos, [50, 100]);

let [_, fifties @ 1..3, _] = x; // error
assert_eq!(fifties, [-50, 50])

However with the feature as implemented, the pattern [..x, x..] doesn't mean "match an array of arbitrary length and split it array into two at index x", it means "match an array of exactly two elements, where the first element's value is less than x and the second's is greater or equal to x". It's a bit of an unfortunate situation where [..] and [0..] will mean surprisingly different things in pattern context.

The most future-proofed solution here would be to produce a compilation error when encountering a .. at the top level of a slice pattern (excepting RangeFull). This is backwards-compatible with existing [..] slice patterns, and would most likely never be encountered by people trying to use range patterns. And since match 42 { .. => () } is already invalid (can't use .. outside of tuple, tuple struct, and slice patterns), this would leave us in a state where RangeFull patterns, despite meaning something different from the other Range patterns, would be distinct and disjoint in semantics with no ambiguity. And of course it would be backwards-compatible if anybody wanted to lift this restriction in the future, either to allow slicing with RangeFrom et al or to revive the behavior as it is currently implemented (basically, deciding whether you'd rather have 0.. be surprisingly different from [0..], or have [0..] be surprisingly different from [..]).

[workingjubilee]

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

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[workingjubilee]

Assuming I understand @bstrie's remarks correctly, I will update this PR with the appropriate restrictions as suggested, unless there is a broad consensus otherwise, because I did not adequately address this in my stabilization report. This should not be merged until then. I am marking this as a draft for the moment until this is resolved (i.e. I reapply this feature gate for slices and itemize the slice syntax concerns in the appropriate issues). Hopefully I get around to this Sooner rather than Later.

TODO: Done.

• Feature-restrict RangeFrom in slice patterns
• More clearly itemize the relevant concerns in issue Tracking issue for ..X, and ..=X (#![feature(half_open_range_patterns)]) #67264
• Also itemize the relevant concerns in issue Tracking issue for exclusive range patterns #37854

[bstrie]

I'm not qualified to comment on the implementation but the tests look good to me. 👍 Thanks!

[workingjubilee]

Excellent,
and followup comments have been added to the appropriate tracking issues.
I consider this satisfactory and it is ready to merge.

[nikomatsakis]

I'm trying to remember where our discussion left off in the last lang team meeting and/or on Zulip. I am still feeling rather unconvinced that we should feature gate patterns like this. I feel like having range patterns not compose within slice patterns feels rather surprising to me, and I don't think using the same syntax for some other meaning seems very likely.

[workingjubilee]

Mmm, I agree with bstrie that there is syntactic conflict with SliceIndex. All the code where I write destructuring slices, very often byteslices, would be neater and simpler if it could use a pattern like

let [octobyte 0..8, rest @ ..] = byteslice;
let num = u64::from_le_bytes(octobyte);

Instead, to do that, I have to use

let [a, b, c, d, e, f, g, h, rest @ ..] = byteslice;
let num = u64::from_le_bytes([a, b, c, d, e, f, g, h]);

And yes, I have written variants of the above several times. I don't consider the .try_into().unwrap() case less bad. It's agreed that range patterns are rare in slices... and I think they are rare because what a user would really expect, where a range pattern inside a slice pattern works like SliceIndex, doesn't work.

In any case, I did not adequately address the conflict between range patterns and slice patterns in my stabilization report, even though it was mentioned in the issue, because I didn't understand it. I reestablished the feature gate only because that seemed like the most minimal possible proofing to allow further attention to be paid to it, and assume even that will be obviated in short order by future actions. We could also make it fail to compile in this PR, or cancel incremental stabilization of range patterns and wait for a full RFC on the whole shindig. All of those seem like valid ways to address the concern... otherwise why wait for final comment periods if we don't address concerns in those comments?

I understand it's all a very weird and unsatisfying situation, mind, I just feel prematurely settling things would be even more unsatisfying.

[joshtriplett]

@rfcbot concern consider-alternative-further

@workingjubilee, can you start a new thread in the lang Zulip stream to discuss this further, so that we can consider possibilities with you?

[joshtriplett]

Based on discussion with @workingjubilee, it sounds like the net effect of this PR is to stabilize RangeFrom patterns except for the combination of range patterns within slice patterns. That allows for further evaluation of how to make those compatible in the most intuitive and least confusing way we can.

I think it's appropriate to go ahead with a partial stabilization here. Even if we want to stabilize range patterns within slice patterns as well, I think it's reasonable to do that in a separate PR that discusses the tradeoffs, rather than complicating this PR.

We're not making an irreversible decision to stabilize something that would commit us down one or the other path; rather, we're intentionally only stabilizing the subset that still allows us to make that decision separately in the future.

Given that:

@rfcbot resolved consider-alternative-further

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[inquisitivecrystal]

I think that rfcbot may have gotten confused by the fact that this went through FCP again after the FCP had finished once. It looks to me like the FCP is now over and this is ready to merge, though I could be missing something.

[workingjubilee]

You are correct.
@bors r=joshtriplett

[bors]

📌 Commit 43bad44 has been approved by joshtriplett

[bors]

⌛ Testing commit 43bad44 with merge 0d76b73...

[bors]

☀️ Test successful - checks-actions
Approved by: joshtriplett
Pushing 0d76b73 to master...