Allow unreachable patterns in some form

[mahkoh]

A pattern should not be unreachable if the user cannot know that it's unreachable. E.g.

use X::{A, B};

match 1u {
    A | B => { },
    _ => { },
}

should never be an error even if A == B.

[mahkoh]

The current status implies that changing a public constant is an API breaking semver change.

[ghost]

The current status implies that changing a public constant is an API breaking semver change.

This is true. However, constants in patterns are not the only scenario where that can happen. The following example demonstrates how that can occur in a different situation where the values are evaluated at compile time.

use X::{A, B};

fn f() -> [uint, ..A] {
    unreachable!()
}

fn main() {
    let x: [uint, ..B] = f();
}

I am going to close this issue as a dupe of #4112.

In any case, a change of this type would warrant an RFC so if you are interested in pursuing this idea further and submitting a concrete proposal, the RFC process is described here: https://github.com/rust-lang/rfcs#what-the-process-is. Thanks!

[reem]

@mahkoh I can't imagine that changing a public constant is ever not an API breaking semver change.

[mahkoh]

@reem: I'm sure your POSIX compatible C program will compile just fine on all platforms even if the error constants EAGAIN and friends aren't the same everywhere.

[mahkoh]

@jakub- : Your example is not quite the same. In my example above I treat A and B as two constants whose value is unknown or doesn't matter to me. Naturally I cannot assign an array of size A to an array of size B under these conditions. But if the implementation ever changes from A != B to A == B, then the match will break anyway.

[reem]

@mahkoh Not if I have an assertion about the values of those constants. I don't think that this worry is without merit, but we should also recognize that changing the value of a constant is a breaking change in 99% of cases. Additionally, these sorts of things should usually be implemented as enums rather than constants.

[ghost]

@mahkoh Yeah, that was a poor example. Here's another one, though:

trait MyTrait {}
impl MyTrait for [uint, ..A] {}
impl MyTrait for [uint, ..B] {}

This will fail to compile if A == B as that'd mean MyTrait being implemented twice for the same type.

My general point was that changing the value of a constant in a program may indeed change the outcome of typechecking that program if said constant appears in a type.