associated_consts_cannot_be_reference_in_patterns

enum State {
    On,
    Off,
}

trait Foo {
    const STATE: State;
}

struct A;
impl Foo for A {const STATE: State = State::On;}

struct B;
impl Foo for B {const STATE: State = State::On;}

fn f<T: Foo>(s: State) {
    match s {
        T::STATE => {}
        State::Off => {}
    }
}

fn main() {}

Hmm... Does anyone happen to know why "associated consts cannot be referenced in patterns". Is it something fundamental, or just not something anyone's gotten around to implementing yet?
[11:54] U007D: I think it would interfere with exhaustiveness checking
[11:55] U007D: Or even checking if two patterns are the same
[11:56] stephaneyfx: I can use "regular" (ie. global) consts as a pattern--I can't see why AC's would be different for exhaustiveness?
[11:57] U007D: Because with regular global constants, rustc knows their values when compiling a match
[11:57] U007D: With associated constants, it doesn't as it depends on the type, including types not written yet that may implement the trait defining the constants
[11:58] U007D: I can write an example if it's still unclear
[11:58] stephaneyfx: I would have thought that in any given monomorphized function, all the information (the type and the value) would be known at compile time. Yes, an example would be really helpful, thank you!
[11:58] U007D: But the impl might be in one crate and the match in another
[11:59] U007D: Yes, it is know at monomorphization time, but remember rust is not like C++ in this regard. It needs to know at the point the generic code is written, not when it's instantiated with specific types
[11:59] *known
[12:02] mbrubeck: ah, that makes sense. In that case, full information isn't known until link time, correct?
[12:02] U007D: Well as you say it's known when the function is monorphized, but as stephaneyfx says, that's done after typechecking
[12:03] Rust type-checks the generic function, not specific instantiations
[12:03] So you can tell just from a function signature which types it accepts -- the body can't change this.
[12:05] mbrubeck: stephaneyfx: u guys are good! :) makes sense, thank you!
[12:05] U007D: Consider this example: https://play.rust-lang.org/?gist=8fa2cfd77e5eec96ca02972f02e97e3d&version=stable&mode=debug&edition=2015
[12:05] U007D: rustc has no way of knowing if T::STATE is On or Off
[12:06] U007D: But the definition of f must be type-checked and make sense before it's instantiated with specific types
[12:07] stephaneyfx: wow.
[12:07] stephaneyfx: that's very clear--thanks for the terrific example
[12:08] U007D: You're welcome. I'm glad it helped :)