Cannot move out of destructured fixed length vectors in `let` and `match`

[brendanzab]

struct Vector3<S>(S, S, S);

// passes type checking
fn into_vec3_arg<S>([x, y, z]: [S, ..3]) -> Vector3<S> {
    Vector3(x, y, z)
}

fn into_vec3_let<S>(v: [S, ..3]) -> Vector3<S> {
    let [x, y, z] = v; // error: use of moved value: `v[..]`
    Vector3(x, y, z)
}

fn into_vec3_match<S>(v: [S, ..3]) -> Vector3<S> {
    match v {
        // error: use of moved value: `v[..]`
        [x, y, z] => Vector3(x, y, z),
    }
}

http://is.gd/bc1U2v

Note that it is impossible to work around this using transmute, because:

struct Vector3<S>(S, S, S);

fn into_vec3_transmute<S>(v: [S, ..3]) -> Vector3<S> {
    // error: cannot transmute from a type that contains type parameters
    unsafe { mem::transmute(v) }
}

http://is.gd/BeSWOs

[milibopp]

I am unsure whether it is a good idea, but another workaround involving transmutation to a box is possible and appears to work. (I have a suspicion though that this somehow messes up the memory.)

EDIT: ok, it is a bad idea, see below

struct Vec2<S>(S, S);

fn from_array<S>(arr: [S, ..2]) -> Vec2<S> {
    *unsafe { mem::transmute::<&[S, ..2], Box<Vec2<S>>>(&arr) }
}

[huonw]

That is incorrect and it can corrupt memory/crash the app/anything; it results in calling free on some random pointer into the stack, which is undefined behaviour.

It is more reliable to do:

struct Vec2<S>(S, S);
fn from_array(arr: [S, .. 2]) -> Vec<S> {
    unsafe {
        let x = Vec2(ptr::read(&arr[0]), ptr::read(&arr[1]));
        // stop the destructor running on the values in the array, i.e. transfer ownership:
        mem::forget(arr); 
        x
    }
}

[huonw]

Function arguments working differently suggests to me that there could be some memory safety bugs that are not caught (not with moving out of fixed length arrays directly, but possibly something similar).

[steveklabnik]

Updated code sample: https://play.rust-lang.org/?gist=604564384c576d2d3862&version=nightly

[matthewjasper]

Fixed in MIR borrowck (and so NLL) cc #23121
Dupe of #26736

[Mark-Simulacrum]

Yep, closing as duplicate of #26736.