Tracking issue for pattern with by-move & by-ref bindings

[Centril]

This is the tracking issue for #![feature(move_ref_pattern)], which allows patterns containing both by-ref and by-move bindings at the same time. For example: (ref x, y, ref mut z).

Implementation history

• On 2020-02-09, the implementation of the feature in Initial implementation of #![feature(move_ref_pattern)] #68376 landed, thereby fixing Pattern errors are too imprecise and should be removed in favor of MIR borrowck #45600. The PR was written by @Centril and reviewed by @matthewjasper.

[CryZe]

Does this also address moves in default match bindings like so?

let (x, y) = &(Vec::new(), 2);

where I want x to be a reference, but not y?

Optimally with a syntax like so:

let (x, move y) = &(Vec::new(), 2);

[Centril]

That's unrelated to this issue. (You can achieve move y with mut y, but this requires that y is bound by-copy as opposed to by-move, as you cannot move out of something held under a reference.)

[CryZe]

Oh wow, that is incredibly surprising that mut already somewhat achieves "moves" (yeah it's really bind by copy). Though this seems really dangerous as seen here:

let mut value = (2, true);
let (mut the_int, _) = &mut value;
the_int = 6;

Where it looks like the value would get modified, but instead we are actually modifying a fairly implicit copy. And I guess this doesn't work at all if we just want to bind by copy without actually modifying our copy (at least if you don't want any warnings).

[Centril]

• On 2020-02-09, the implementation of the feature in Initial implementation of #![feature(move_ref_pattern)] #68376 landed, thereby fixing Pattern errors are too imprecise and should be removed in favor of MIR borrowck #45600. The PR was written by @Centril and reviewed by @matthewjasper.

As of now, we don't believe more tests would needed before we stabilize, but if you can think of some, please do add or propose them. What we're waiting now is probably for more time to pass.

[jjpe]

When could this feature potentially be stabilized, assuming no (major) issues are found?
I ask because I would like to optimize a derive-style proc-macro crate I'm writing. Currently the generated code contains a match on 2 by-ref bindings, but performing the optimization would result in one by-ref and one by-move binding in a single match.

Of course the response might be "just use another control flow structure, e.g. if-let", and in principle I could do that. In practice though, because it is code generation code, debugging is harder, and I'd prefer to keep the current code intact as much as possible. So much so that I'd rather wait for this feature to become stable if the amount of time it will take to stabilize is not too great.

[Centril]

So this feature hasn't seen any dogfooding inside the compiler itself, and I don't know what the testing situation in the ecosystem is like. However, the src/test/ui testsuite is extensive, so maybe that is enough. If @matthewjasper thinks this is good enough we could probably stabilize in 1.44.