Match ergonomics means bindings have different types in patterns and match arm; cannot deref references in pattern

[varkor]

Consider the following:

struct S(u32);

fn foo(x: &S) {
    let _: &u32 = match x {
        S(y) => y,
        _ => &0,
    };
}

Here, the variable binding y has type &u32 outside the pattern. However, inside the pattern it has type u32. The fact that these types do not align is confusing, as it means you can't dereference y inside the pattern like this:

fn foo(x: &S) {
    let _: u32 = match x {
        S(&y) => y,
        _ => 0,
    };
}

and instead have to dereference it outside the pattern:

fn foo(x: &S) {
    let _: u32 = match x {
        S(y) => *y,
        _ => 0,
    };
}

Is there any reason this was chosen to be the case, or is required to be the case? As it stands, this behaviour is very counter-intuitive.

[estebank]

I thought that this was the case where you'd want to use ref.

[varkor]

@estebank: could you clarify?

[estebank]

@varkor my bad, I misunderstood what you were talking about. Using S(ref y) makes y be u32. I believe this is only a problem because u32 is Copy, but if it weren't then y would be &u32 inside the match arm block as well.

[CryZe]

However, inside the pattern it has type u32.

Yes, that's the whole point of default match bindings though. The fact that S(...) is matched against a reference means that every binding inside also becomes a reference. The only annoying part is that there's no way to force a move instead of getting a reference in that case.

I think we should absolutely have either S(&y) or S(move y) as otherwise you sometimes still have to resort to the old style of matching, which is just confusing for everyone.

[Emerentius]

It's a somewhat common trick to use let () = value to provoke a type error that tells you what type value really is. With match ergonomics this will only tell you the type modulo references.

let () = &&3u8;
    ^^ expected u8, found ()

This confused me for quite a while.

[varkor]

@Centril pointed out that currently, y acts differently to mut y in patterns, with respect to references (which is absurd). Under my proposed behaviour, the following:

fn foo(x: &S) {
    let _: u32 = match x {
        S(mut y) => y,
        _ => 0,
    };
}

would not type-check, because mut y would have type &u32, but unfortunately it does. I'm not sure how much can be done in light of this.

[RalfJung]

Woah, mut "resets" the binding mode? That is quite absurd indeed.

[Boscop]

@varkor

I'm not sure how much can be done in light of this.

Do you mean that this is preventing us from allowing to move y out with the &y syntax? I don't think so, because we already support moving y combined with making y mut like this:

arr.iter().map(|&(mut y)| .. )

I really hope we can enable a way to move out some pattern constituents explicitly in the presence of match-default-bindings, and I really prefer &x over move x for reasons explained here (consistency & orthogonality): #42640 (comment)

Me and many other people already expected &x to work in this way: #42640 (comment)

I am absolutely floored by the fact that default binding modes don't already work like @Boscop expects. That (apparently incorrect) understanding was part of why I came around to liking them.

(That comment was referring to what I wrote here: #50008)

[varkor]

Do you mean that this is preventing us from allowing to move y out with the &y syntax?

We could probably permit some examples that are currently forbidden, but we would not be able to make it behave consistently (e.g. with regards to mut) without a breaking change, so this would be ad hoc at best. It's debatable whether this would be an improvement, and also whether it would be worth considering changing the behaviour in a new edition.

[Centril]

@varkor Before considering using the edition mechanism, I think it would be prudent to crater run a change and see if anyone is relying on the mut x resetting.