I am under the impression that #5016 will make zeroing or not zeroing both unsafe here, since moves will be tracked precisely to run destructors exactly when appropriate and so moving out from behind a `&mut` won't be tracked properly, leaving an invalid slot upon which destructors will be run.

I'm extremely concerned about this code here due to this. I think the only (long-term) safe way is to have a wrapper type with a destructor that carefully manages the hole in the `Vec`, to avoid the `Vec` destructor running a destructor on the invalid slot.

Something like (untested)

```rust
struct VecInPlaceMut<T> {
     v: Vec<T>,
     hole_plus_one: uint
}

impl Drop<T> {
    fn drop(&mut self) {
        if self.hole_plus_one == 0 || self.hole_plus_one == self.v.len() + 1 { return } // no invalid data, run normally
        unsafe {
            // destroy everything but the invalid place
            for p in self.v.slice_to(self.hole_plus_one - 1) {
                ptr::read(p);
            }
            for p in self.v.slice_from(self.hole_plus_one ) {
                ptr::read(p);
            }
            self.v.set_len(0);
        }
    }
}

fn vec_map_in_place<T>(v: Vec<T>, f: |T| -> T) -> Vec<T> {
    let mut map_in_place = VecMapInPlace { v: v, hole_plus_one: 0 };
    for place in map_in_place.mut_iter() {
        let value = ptr::read(place);
        // order is important: this must be between "moving out" and calling `f`
        map_in_place.hole_plus_one += 1;
        *place = f(value);
    }
    map_in_place.v
}
```

A similar thing should be done with `Box`, by writing a wrapper type where the destructor just calls the appropriate `free` function (i.e. doesn't run the destructor on the invalid moved-out slot).