Permit mutation of `&mut` pointers whose pointees have been borrowed

[nikomatsakis]

Now that the swap operator has been removed, I do not believe the
restriction against mutating LV is needed, and in fact it prevents
some useful patterns. For example, the following function will
fail to compile:

       fn mut_shift_ref<'a,T>(x: &mut &'a mut [T]) -> &'a mut T {
           // `mut_split` will restrict mutation against *x:
           let (head, tail) = (*x).mut_split(1);

           // Hence mutating `*x` yields an error here:
           *x = tail;
           &mut head[0]
       }

Note that this function -- which adjusts the slice *x in place so
that it no longer contains the head element and then returns a
pointer to that element separately -- is perfectly valid. It is
currently implemented using unsafe code. I believe that now that
the swap operator is removed from the language, we could liberalize
the rules and make this function be accepted normally. The idea
would be to have the assignment to *x kill the loans of *x and
its subpaths -- after all, those subpaths are no longer accessible
through *x, since it has been overwritten with a new value. Thus
those subpaths are only accessible through prior existing borrows
of *x, if any. The danger of the swap operator was that it
allowed *x to be mutated without making the subpaths of *x
inaccessible: worse, they became accessible through a new path (I
suppose that we could have supported a swap operator, too, if needed, by moving the loans over to the new path).

[pnkfelix]

cc me

[nikomatsakis]

Issue #11558 includes another example.

[huonw]

Triage, no change that I know of.

[nikomatsakis]

This may have become more important. As part of #20341, we started doing coercions on assignments of the form:

x = y

If x has type &mut X, then this causes a reborrow of y whereas it used to cause a move. Unfortunately, this can break code that used to work. Here is a reduced example:

fn foo(mut vec: Vec<int>) {
    let mut iter = vec.iter_mut();
    let mut cur = iter.next().unwrap();
    let mut next = iter.next().unwrap();
    loop {
        *next = 22; // ERROR cannot assign to `next` because it is borrowed
        cur = next; // NOTE borrowed here
        next = iter.next().unwrap();
    }
}
fn main() {}

This can be worked around by forcing a move using a dummy newtype:

struct Dummy<T>(T);

fn foo(mut vec: Vec<isize>) {
    let mut iter = vec.iter_mut();
    let mut cur = Dummy(iter.next().unwrap());
    let mut next = iter.next().unwrap();
    loop {
        *next = 22;
        cur = Dummy(next);
        next = iter.next().unwrap();
    }
}
fn main() {}

But that's awful!

[nikomatsakis]

Nominating because it may be worth trying to fix this for ergonomic reasons (or else maybe reverting the coercion change).

[brson]

Triage: closing. Old wishlist. Do RFC.

[shepmaster]

Zombie revivification. The updated example is

fn foo(mut vec: Vec<i32>) {
    let mut iter = vec.iter_mut();
    let mut cur = iter.next().unwrap();
    let mut next = iter.next().unwrap();
    loop {
        *next = 22;
        cur = next;
        next = iter.next().unwrap();
    }
}
fn main() {}

And error:

error[E0506]: cannot assign to `*next` because it is borrowed
 --> src/main.rs:6:9
  |
6 |         *next = 22;
  |         ^^^^^^^^^^ assignment to borrowed `*next` occurs here
7 |         cur = next;
  |               ---- borrow of `*next` occurs here

error[E0499]: cannot borrow `*next` as mutable more than once at a time
  --> src/main.rs:7:15
   |
7  |         cur = next;
   |               ^^^^ mutable borrow starts here in previous iteration of loop
...
10 | }
   | - mutable borrow ends here

error[E0506]: cannot assign to `next` because it is borrowed
 --> src/main.rs:8:9
  |
7 |         cur = next;
  |               ---- borrow of `next` occurs here
8 |         next = iter.next().unwrap();
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^ assignment to borrowed `next` occurs here

This code now compiles with NLL enabled.