Exhaustive match of number treated as non-exhaustive

[ebiggers]

The following function does not compile because rustc determines that the patterns in the match statement are non-exhaustive. However, the pattern matches every possible value of the integer type, and the compiler should be able to detect this.

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

[jkleint]

I assume this is the same issue:

fn main() {
    println!("{}", match 1i {
        n if n > 0  => "greater",
        n if n < 0  => "less",
        n if n == 0 => "equal",
    });
}
// error: non-exhaustive patterns: `_` not covered [E0004]

[thecoshman]

Whilst I agree that your example is exhaustive, it's not a good example.

match 1i {
    n if n > 0  => "greater",
    n if n < 0  => "less",
    _ => "equal",
}

This is effectively the same, except it compiles. Keep in mind match checks the patterns in order. You wouldn't write:

if (n > 0) { "greater" } 
else if (n < 0) { "less" }
else if (n == 0) { "equal" }

you would just drop the 'if (n == 0)' from that last clause.

[drewm1980]

Doing the test for n==0 is less efficient, but IMHO more readable. I would probably use your pattern but leave n==0 commented out.

[steveklabnik]

The compiler is never going to be able to fully determine these kinds of things, as they would involve evaluating certain things at compile time. For example:

0x00 ... (0xff + 1 - 1) => { }

This arm would be equivalent, but would report as non-exhaustive, too.

As such, I'm giving this a close. I don't think we can improve this.

[chris-morgan]

@steveklabnik I disagree with your closing of this issue; could you please open it again? The issue is entirely genuine, is blocking correct code (though admittedly there is an easy workaround: change the last pattern to an _) and is a nuisance.

Moreover, your fabricated example is invalid, because you can’t do arithmetic in patterns.

@jkleint Your example is a completely different issue and is not solvable. n > 0 || n < 0 || n == 0 is not necessarily true, though it is declared by the programmer to be true if Eq and Ord are implemented for the type.

[steveklabnik]

@chris-morgan I'm not understanding how this issue is solvable. To grok the range, we need to evaluate code at compile time, it can't work.

[chris-morgan]

@steveklabnik it’s a pattern, so the numbers are literals or constants. No additional evaluation required. The compiler needs to know them in order to compile the code anyway.

[jkleint]

@chris-morgan aren't Eq and Ord implemented for integers? My example was an integer. :)

[constancebello]

I've written a POC script that compares a set of ranges with 1 or more exhaustive ranges for the respective type and outputs any ranges that are not covered: https://gist.github.com/aarzee/4395cb34eef31ea4e5c4

I'm interested in implementing this logic in the compiler but looking at check_match.rs I have absolutely no idea how I would do this. Also, this code has opportunities to take advantage of more types in the future, as currently floats aren't supported by it, and specialization and native inclusive ranges have not yet been added to the language.

[jonas-schievink]

Implementing this would cause the following to fail to compile since the last arm is unreachable:

match 0u8 {
    0...255 => {}
    _ => {}
}

Should a warning be emitted first? Is an RFC needed? Should this be ignored without warning, like it is now? Make it a deny-by-default Lint to prevent breaking dependencies? So many questions!