Tracking issue for exclusive range patterns

[oli-obk]

Summary

This feature allows exclusive integer ranges (such as 0..100) in patterns.

fn is_digit(x: u32) -> bool {
    match x {
        0..10 => true,
        10.. => false,
    }
}

Concerns

• Conflict with the syntax of slice patterns Tracking issue for RFC #495 (features slice_patterns and advanced_slice_patterns) #23121
  • Tracking issue for #![feature(slice_patterns)] #62254 (comment)
• General concern about the syntax of inclusive/exclusive patterns

History and status

• Proposed and implemented in PR exclusive range patterns #35712
  • approved provisionally by lang team without an RFC

[ghost]

EDIT: the following is no longer true 12 jan 2019 nightly debug 2018:

Missing warning: unreachable pattern in the case when 1...10 then 1..10 are present in that order. That warning is present in case of 1..12 then 1..11 for example.

Example (playground link):

#![feature(exclusive_range_pattern)]
fn main() {
    let i = 9; //this hits whichever branch is first in the match without warning
    match i {
        1...10 => println!("hit inclusive"),
        1..10 => println!("hit exclusive"),//FIXME: there's no warning here
        // ^ can shuffle the above two, still no warnings.
        1...10 => println!("hit inclusive2"),//this does get warning: unreachable pattern
        1..10 => println!("hit exclusive2"),//this also gets warning: unreachable pattern

        _ => (),
    };

    //expecting a warning like in this:
    match i {
        1..12 => println!("hit 12"),
        1..11 => println!("hit 11"),//warning: unreachable pattern
        _ => (),
    }
}

[richard-uk1]

I've just been saved for the second time by the compiler when I did 1 .. 10, but meant 1 ..= 10. It might be worth considering that the compiler won't catch this error if exclusive ranges are allowed.

[donbright]

seems like exclusive range match would help to improve consistency ... why can i do range in a loop but not in a pattern?

 const MAXN:usize = 14;
 ... 
   for x in 0..MAXN  { blahblahblah(); }
 ...
   let s = match n {
      0..MAXN=>borkbork(),
      MAXN=>lastone(),
      _=>urgh(),
   };

also note that the following is not possible currently because the -1 will break the compile with "expected one of ::, =>, if, or | here"

   let s = match n {
      0..=MAXN-1=>borkbork(),
      MAXN=>lastone(),
      _=>urgh(),
   };

thank you

[kentfredric]

@donbright I know its a poor consolation, but a good workaround which ensures backwards compatibility might be:

        match i {
            0..=MAXN if i < MAXN => println!("Exclusive: {}", i),
            MAXN => println!("Limit: {}", i),
            _ => println!("Out of range: {}", i)
        }

playground

Figured this suggestion might help some poor soul who came here and also battled with not being allowed to use 0..=MAXN-1

[bcantrill]

It doesn't sound like much is going to happen on this issue, but (FWIW) I would argue against its inclusion in stable Rust: exclusive ranges on pattern matching makes it very easy to introduce bugs, as exclusive ranges are very rarely what the programmer wants in a pattern match (emphasis on match!). In these cases, I would argue that having the programmer be explicit is helpful; there is no reason to offer syntactic sugar in this case. (I landed here because of finding several bugs in a project that had turned this feature on; see tock/tock#1544 for details.)

[dumindu]

To consistent with for and other cases,

• either we have to support both inclusive and exclusive patterns in match.
• or either we should deprecate exclusive patterns in both places.

// 0 to 10 (10 exclusive)
for a in 0..10 { 
  println!("Current value : {}", a);
}

// 0 to 10 (10 inclusive)
for a in 0..=10 { 
  println!("Current value : {}", a);
}

let tshirt_width = 20;
let tshirt_size = match tshirt_width {
    16 => "S",       // 16
    17 | 18 => "M",  // 17 or 18
    19..21 => "L",   // 19 to 21; 21 excusive (19,20)
    21..=24 => "xL", // 21 to 24; 24 inclusive (21,22,23,24)
    25 => "XXL",
    _ => "Not Available",
};

While we having inconsistencies like this even in smallest things, it's more harder for newcomers to learn and master Rust.

[kentfredric]

ranges are very rarely what the programmer wants in a pattern match (emphasis on match!)

Arguments like that IMO are better grounds for lints, not "you can't have this".

Otherwise I'd be arguing you shouldn't be allowed to have a thing.is_file(), because it sometimes isn't what you expect: Usually you just want a readable thing that isn't a directory, and things like pipes and symbolic links and device nodes are acceptable, even if weird... but .is_file() will likely exclude those options for you. ( Hence why I proposed a lint for that )

And lets not even get into the rabbit warren of "stating files is bad, because you could have the underlying file change between the stat time and the time you modify it, use proper error handling instead" argument, because while I agree in part, its a decision you should make after understanding a lint telling you "why this is probably bad" and you decide whether or not it matters for your code.

[harrysarson]

If I may add a datapoint. I tried to use an exclusive range today and the compiler error took me here. Turned out I wanted an inclusive range, so I for one am greatful that rust does not (stabley) allow exclusive ranges and I would argue against stablising as it would have caused me to shoot myself in the foot. :)

[avl]

I wanted exclusive ranges today, for a case where I had a variable that needed to be handled differently depending on which of the following ranges it fell into: 0..10, 10..100, 100..1000 and 1000..10000. In my opinion the code would have been cleaner if exclusive ranges were supported.

[phaux]

for a case where I had a variable that needed to be handled differently depending on which of the following ranges it fell into: 0..10, 10..100, 100..1000 and 1000..10000.

You could just do a match on x.log10().floor()

[avl]

for a case where I had a variable that needed to be handled differently depending on which of the following ranges it fell into: 0..10, 10..100, 100..1000 and 1000..10000.

You could just do a match on x.log10().floor()

Yeah, good point! But at least to me, it wouldn't be as readable. The match would be something like:

0 => /* handle  case 0..10 */,
1 => /* handle case 10..100 */,
2 => /* handle case 100..1000 */,

Which isn't bad, but without the comment it wouldn't be immediately obvious that the case "0" handled the range 0..10 .

[workingjubilee]

It is not clear that

0..=9
10..=99
100..=999
1000..=9999

is less desirable.

However I would like to voice that I prefer having the option to have an exclusive range pattern for the sole case of the "half-open range" (#67264) that goes from a certain value unto the natural end of that range

[Nadrieril]

This is not the place to report bugs :)

[Nadrieril]

(you're right that this is surprising though, feel free to open an issue to suggest a diagnostic that explains the confusion)

[MultisampledNight]

I'd want to tackle making a stabilization PR this weekend, if no one else has done it until then!

[MultisampledNight]

I most professionally forgot about this xD. A bit busy right now, I'll try to come back to this in a few weeks.

[Nadrieril]

#124459 is merged, the feature is now stabilized! 🎉 Rust 1.80.0 will support exclusive integer ranges in patterns.

Thank you to everyone who participated in any way over the 8 years since this feature started.

@rustbot label +relnotes