Matches on &mut[] move the .. match & don't consider disjointness

[huonw]

I believe the following should work, since head and tail are disjoint, and tail is just taking a slice into v (this would mean that v is inaccessible while the result of mut_head_tail is kept around):

fn mut_head_tail<'a, A>(v: &'a mut [A]) -> Option<(&'a mut A, &'a mut [A])> {
    match v {
        [ref mut head, .. tail] => {
            Some((head, tail))
        }
        [] => None
    }

    /* // this works currently:
    if v.is_empty() {
        None
    } else {
        let (low, hi) = v.mut_split(1);
        Some((&mut low[0], hi))
    }
    */
}

fn main() {
    let mut v = ~[1,2,3,4];

    match mut_head_tail(v) {
        None => {},
        Some((h,t)) => {
            *h = 1000;
            t.reverse();
        }
    }

    println!("{:?}", v);
}

mut-vec-match.rs:3:26: 3:30 error: cannot bind by-move and by-ref in the same pattern
mut-vec-match.rs:3         [ref mut head, .. tail] => {
                                             ^~~~
mut-vec-match.rs:3:9: 3:21 note: by-ref binding occurs here
mut-vec-match.rs:3         [ref mut head, .. tail] => {
                            ^~~~~~~~~~~~
error: aborting due to previous error

Changing it to (and removing the t.reverse()):

fn mut_head_tail<'a, A>(v: &'a mut [A]) -> Option<(&'a mut A, ())> {
    match v {
        [ref mut head, .. ref mut _tail] => {
            Some((head, ()))
        }
        [] => None
    }
}

mut-vec-match.rs:21:9: 21:21 error: cannot borrow `(*v)[]` as mutable more than once at a time
mut-vec-match.rs:21         [ref mut head, .. ref mut _tail] => {
                             ^~~~~~~~~~~~
mut-vec-match.rs:21:8: 21:40 note: second borrow of `(*v)[]` as mutable occurs here
mut-vec-match.rs:21         [ref mut head, .. ref mut _tail] => {
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error

[tikue]

Generally, multiple ref mut in a vector pattern should be allowable:

let mut v = [1, 2, 3];
match v {
    [ref mut x, ref mut y, ref mut z] => {
        *x += 1;
        *y += 1;
        *z += 1;
    }
}

<anon>:9:53: 9:62 error: cannot borrow `v[]` as mutable more than once at a time
<anon>:9         let mut v = [1, 2, 3]; match v { [ref mut x, ref mut y, ref mut z] => { *x += 1; *y += 1; *z += 1 } }
                                                              ^~~~~~~~~
<anon>:9:42: 9:51 note: second borrow of `v[]` as mutable occurs here
<anon>:9         let mut v = [1, 2, 3]; match v { [ref mut x, ref mut y, ref mut z] => { *x += 1; *y += 1; *z += 1 } }
                                                   ^~~~~~~~~
...

error: aborting due to 3 previous errors
application terminated with error code 101

[nikomatsakis]

cc me

[glaebhoerl]

An interesting subquestion is whether we also want this to be allowed:

match vec {
    [ref mut a, _] => match vec {
        [_, ref mut b] => { ... }
    }
}

In other words, whether the borrow checker should know about and attempt to reason about the disjointness of borrows into a vec beyond the scope of an individual pattern match.

[nikomatsakis]

Depending on how we do the implementation, it's likely that both patterns would "just work".

[reem]

Triage: Nothing has changed here, at least as it pertains to &mut [T], would be pretty cool if it worked.

[arielb1]

This limitation doesn't have anything to do with slice patterns. It is even well-documented as E0009.

[huonw]

@arielb1 I don't think it is the same, e.g. for the first example in the issue, an ident .. binding in a slice pattern is actually binding by reference (it has type &mut [_] or &[_], not [_]), and the second one is completely unrelated.

[matthewjasper]

Updated code:

#![feature(slice_patterns)]
fn mut_head_tail<'a, A>(v: &'a mut [A]) -> Option<(&'a mut A, &'a mut [A])> {
    match *v {
        [ref mut head, ref mut tail..] => {
            Some((head, tail))
        }
        [..] => None
    }
}

See also:

rust/src/librustc_mir/borrow_check/mod.rs

Lines 1743 to 1746 in ee220da

	// FIXME(#8636) we might want to return Disjoint if
	// both projections are constant and disjoint.
	debug!("place_element_conflict: DISJOINT-OR-EQ-ARRAY");
	Overlap::EqualOrDisjoint