Cannot deconstruct reference inside match on reference—why?

Suppose I match on a tuple using a reference:

let _ = &(a, b);

If I then want a reference of one element but a copy of another, why can’t I write this?

let (c /* c = &a */, &d /* d = b */) = &(a, b);

(of course, suppose I wasn’t matching on &(a, b), but on a function that returned a tuple with something interesting)

Why is this?

1 Like

Here the types don't line up at all. If you had written let (a, b) = &(a, b); then match ergonomics would have kicked in, but that's merely the compiler trying to outsmart you; it shouldn't work based only on the types.

If you want a reference of one field and a copy of another, then be explicit and make types actually match:

let &(copy, ref non_copy) = &(a, b);

I answered what was essentially the same question fairly recently here:


Can you, then, change the “binding mode” back to be moves?

The way to express the “reference of one element but a copy of another” is, like @H2CO3 explained as well, to avoid the “match ergonomics” and write a & before the tuple pattern, so instead of let (c, &d) = &(a, b); (which does not compile), you’ll want let &(ref c, d) = &(a, b);.

As I explained in the other response there is no syntax in Rust, if you are using match ergonomics, to change the binding mode back to moves, except for the fact that the mut binding mode can be (ab-)used to do this (see towards the end of the linked post), but that wouldn’t be very nice code.

I feel like it would be a good idea to use the move keyword to change the binding mode back to moves.

I personally feel like for more complex cases, avoiding match ergonomics is a fine approach, and introducing new keywords to write the same thing using different syntax only adds confusion and complication. The thing I would probably want to change about the current situation is to allow any binding mode annotations in places where the default binding mode is altered by match ergonomics, so the confusing effects that ref x or ref mut x might be equivalent to x in some places, or that mut x changes the binding mode back to by-value, could be avoided, simply by means of disallowing (or at least linting against) such syntax in the relevant places in the first place.

But at that point, you are (a) using two different kind of features intermixed, and (b) you have complicated it even more by introducing more syntax. You should really just make the types match, it's not any harder or longer.

It is an obvious inconsistency that there is no way to explicitly indicate the move binding mode when the default binding mode can be changed. What you are saying here makes it sound like match ergonomics themselves are a misfeature.

The only other syntax that does make some sense to me is to use &x after all, like you imagined it… kind of following the premise of my linked answer which starts out

What you probably imagine is that let (PAT1, PAT2) = r; with r: &(S, T) will create a &S and match it against PAT1 ; as well as creating a &T and matching it against PAT2 . That’s not what happens.

and thus has me wondering, what if it was actually what happens? Would that be a nice and consistent experience? (At least it would avoid the need for more keywords.. I have thought so little about this idea that I might very well overlook good reasons against such an approach.)

Of course given the precedent of the syntax currently having different meaning from that interpretation means a lot of breaking changes, presumably over an edition, and that raises question if that would be worth the churn.

Also I notice there is no warning for using ref when the binding mode is already referential. It seems to me that that might be worth a change, no?

Right, as I indicated above, I personally believe it might be worth a change to lint in general against any ref x, ref mut x or mut x that appears in places where match ergonomics have changed the default binding mode. Linting against redundant ref x in shared-reference default binding mode contexts, or against ref mut x in mutable-reference default binding mode contexts, seems like a very safe first step that might not even need much discussion, but merely an implementation; if nothing else, i.e. even if there are reasons against making it a rustc lint, it’s a strong contender for a clippy lint.

1 Like

You wouldn't be alone in that opinion. From the other thread:

You can deny binding modes with the Clippy lint if you like.

for better or for worse, I have made an RFC about this topic

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.