Compiler rejects cast in match arm

[bnoordhuis]

At commit a5ab960. I would expect the following to work:

fn main() {
    match -1 as u32 {
        -1 as u32 => None,
        val => Some(val),
    };
}

But the compiler rejects it with the following error:

$ rustc t.rs
t.rs:3:12: 3:14 error: expected `=>` but found `as`
t.rs:3         -1 as u32  => None,

[huonw]

This is working as designed: we used to allow arbitrary constant expressions in patterns, but this was removed in db0693a .

There are (at least) two options:

• just write -1 instead of -1 as u32 (note that -1 is actually a valid u32 literal, despite being "negative")
• define a static like static ERROR_VAL: u32 = -1; and use ERROR_VAL as the pattern

[bnoordhuis]

Thanks for the suggestion. I tried something like that actually but it doesn't seem to work for all types. Here's an example:

fn main() {
    use std::libc::c_void;
    static ICONV_ERROR: *c_void = -1 as *c_void;
    match -1 as *c_void {
        ICONV_ERROR => None,
        val => Some(val),
    };
}

$ cat t.rs
t.rs:3:35: 3:48 error: Can't cast this type
t.rs:3     static ICONV_ERROR: *c_void = -1 as *c_void;

It's kind of strange because std::libc uses the same pattern.

Do you know what the rationale for commit db0693a was? It doesn't seem like an improvement from my point of view as a user.

[huonw]

Ah, looks like we don't support casts to raw pointers in const-expressions (yet). In this case you may be reduced to just using if pointer == -1 as *c_void { None } else { Some(pointer) }, unfortunately.

I don't remember the exact context, and, as you can see, the commit message is rather terse (as is the pull request: #6417). However, I believe it was simplifying the language and making the pattern grammar more sensible (previously, it wasn't clear if 1 | 2 was matching 3 (i.e. bitwise or of 1 and 2) or matching 1 or 2; now it can only be the latter). I could be incorrect.

[bnoordhuis]

Thanks, that makes sense. The asymmetry between match predicates and normal expressions is somewhat displeasing but I can see the point of removing ambiguity from the language.

(EDIT: Though in the case of casts there is never any ambiguity, I think? Or is there?)

[Cxarli]

Sorry for necroposting but this was the first issue I found when googling for "Rust cast in match arm".

Something like

const TEN: u32 = 10;

fn main() {
    let x: u64 = 20;

    match x {
        TEN as u64 => { /* ... */ },
        _          => { /* ... */ },
    }
}

still doesn't compile on rustc 1.40.0. However, I've found the following workaround which I wanted to share with anyone from the future who comes here by googling like me:

const TEN: u32 = 10;

fn main() {
    let x: u64 = 20;

    match x {
        a if a == TEN as u64 => { /* ... */ },
        _                    => { /* ... */ },
    }
}

If you move the cast to inside the if expression it's all fine.

(of course here it'd be trivial to match x as u32 or const TEN: u64 but imagine that's unwanted for the sake of the example)

[blagowtf]

Hello, just passing by to say i was bitten by this when trying to write code like the following:

enum XX {
  A = 0,
  B = 1,
  C = 2,
}

let x: u64 = ...;
match x {
   XX::A as u64 => XX::A,
  XX::B as u64 => XX::B,
   XX::C as u64 => XX::C,
  _=> panic!()
}

I can hardcode the values but it would have been great to use the cast values in the pattern.

[twvd]

I also just ran into this, when trying to match an i32 against byte literals. Would be very nice if this could be reconsidered..