/rfcs

New issue

Precise range exhaustiveness check for match on integer patterns #1550

Open
pnkfelix opened this Issue Mar 21, 2016 · 5 comments

Assignees

No one assigned

Labels

postponed T-lang

Projects

None yet

Milestone

No milestone

7 participants

@pnkfelix @oli-obk @jonas-schievink @igor-krawczuk @burdges @glaebhoerl @nrc
@pnkfelix
Member
pnkfelix commented Mar 21, 2016

In theory the compiler should be able to detect that the following range is exhaustive and not error about non-exaustive match:

fn wont_compile(x : u8) { 
    match (x) {
        0x00 ... 0xff => { }
    }
}

Proposed (as a side-portion) in #880

Discussed in rust-lang/rust#12483 and rust-lang/rust#32381
@pnkfelix pnkfelix added the postponed label Mar 21, 2016
@pnkfelix pnkfelix referenced this issue Mar 21, 2016
Closed

Improvements to range match patterns #880

@oli-obk
Contributor
oli-obk commented Mar 22, 2016

The following will then error due to _ being unreachable, but it currently is allowed. So we'd need some way to prevent "new" unreachable patterns from being a hard error.

match x {
    0x00...0xFF => {},
    _ => {},
}
@jonas-schievink
jonas-schievink commented Mar 22, 2016

@oli-obk We could just warn in that case (and make it a lint so people can #[deny] or #[allow] it, depending on what they want)
@nrc nrc added the T-lang label Aug 18, 2016
@igor-krawczuk
igor-krawczuk commented Jan 5, 2017 • edited

Are there any new discussion/plans on this? Adding a warning which can be turned off for legacy code seems like the most elegant solution to me. If that aligns with the consensus, I'd try and take a shot at this during my spring vacation and send a pull request
@burdges
burdges commented Jan 5, 2017

It's another issue, and likely unsolvable, but this also fails the range exhaustiveness check:

match x & 0x03 {
    0 .. 3 => ..
}
@glaebhoerl
Contributor
glaebhoerl commented Jan 6, 2017

@igor-krawczuk Unreachable patterns have already been downgraded from errors to warnings in rust-lang/rust#38069 I believe, so that sounds reasonable to me.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment