Any old type of constant can be used in a pattern

[nikomatsakis]

Example:

struct Foo<T> {
    value: T
}

const F: Foo<int> = Foo { value: 2 };

fn main() {
    let x = Foo { value: 2 };
    match x {
        F => { println!("Hi"); }
        _ => { println!("Ho"); }
    }
}

I feel pretty sure that we would want matching to use a PartialEq impl. For now constant patterns should be limited to uint/int/&str. I'll throw it into a patch I'm working on.

[Thiez]

Surely if you wanted the comparison to use PartialEq, you would do

#[deriving(PartialEq)]
struct Foo<T> {
    value: T
}

const F: Foo<int> = Foo { value: 2 };

fn main() {
    let x = Foo { value: 2 };
    match x {
        _ if x == F => { println!("Hi"); }
        _ => { println!("Ho"); }
    }
}

Why remove the possibly useful behaviour of using constants as a pattern?

[ftxqxd]

I was under the impression that consts basically have their values inserted into their use sites. That would make this a perfectly valid example. If we required PartialEq, then we might as well allow statics in patterns as well. I certainly don’t think we should implicitly run PartialEq::eq when pattern matching on constants, so it seems strange to require PartialEq to be implemented if the implementation’s never going to be used.

[nikomatsakis]

So, all I'd like to do for this bug is to ensure that we limit the types of such constants to scalars (and maybe tuples of scalars), which I'm sure we can all agree ought to work. We can hash out our disagreements about what the correct semantics ought to be over an RFC, I imagine.

But for the record:

1. I think that the current system breaks encapsulation. The fields of that structure are private, we shouldn't implicitly accessing and comparing them. We don't know what "equality" means for this struct.
2. Put another way, I think that match foo { CONSTANT => { ... } } and match foo { _ if foo == CONSTANT => { ... } } ought to be equivalent.
3. As a consequence, I do think we should invoke PartialEq from within the match code, which is why I would want to require that it be implemented.

[pythonesque]

I really can't agree on this. I don't expect pattern matching to run arbitrary code (which is what running the PartialEq implementation would do). If the two things in your second bullet are supposed to be equivalent, I don't see why matching on a constant should even be allowed, since it doesn't provide any additional functionality over pattern guards.

[nikomatsakis]

It appears this bug was closed accidentally. I still think this is something we'll have to resolve -- right now, you can match on types that don't implement PartialEq at all, and if they do implement it, the match code semantics do not align with what PartialEq implements. This seems bad. Having match x { FOO => ... } and match x { y if x == FOO => } both be accepted but different in subtle ways seems clearly suboptimal to me.

[nikomatsakis]

I'll note that in the MIR desugaring branch this becomes much easier to handle.

[nikomatsakis]

triage: P-medium