Tracking issue for exclusive range patterns

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

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.

Print battery level

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

add #![feature(exclusive_range_pattern)]

@donbright

@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

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.)

Rollup merge of rust-lang#67712 - Centril:stabilize-slice_patterns, r…

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

Rollup merge of rust-lang#124459 - RossSmyth:stable_range, r=davidtwco

Auto merge of rust-lang#124459 - RossSmyth:stable_range, r=davidtwco

@rustbot

#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

Rollup merge of rust-lang#124749 - RossSmyth:stable_range, r=davidtwco

Unrolled build for rust-lang#124749

Rollup merge of #124749 - RossSmyth:stable_range, r=davidtwco

Fix compile error when compiling with rust 1.79.0 or earlier

patterns: include new exclusive range patterns

Update ruzstd from 0.7 to 0.8

Navigation Menu

Repository navigation

Tracking issue for exclusive range patterns #37854

Summary

Concerns

History and status

131 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for exclusive range patterns #37854

Description

Summary

Concerns

History and status

Activity

richard-uk1 commented on Jun 5, 2018

donbright commented on Jan 12, 2019

kentfredric commented on Jun 26, 2019

bcantrill commented on Jan 16, 2020

131 remaining items

MultisampledNight commented on Apr 15, 2024

Nadrieril commented on May 5, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions