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.