Tracking Issue for Mutex and RWLock unique accessors

[Gankro]

After #29031, this is now the tracking issue for the stabilization of the following features:

• mutex_into_inner
• mutex_get_mut
• rwlock_into_inner
• rwlock_get_mut

Original report

As far as I can tell, it's sound to straight-up-unwrap a Mutex if you have it by value. This would enable one to do:

let data = Mutex::new(vec![])
crossbeam::scope(|scope| {
  for input in inputs {
    let data = &data;
    scope.spawn(move || {
      let output = expensive_computation(input);
      data.lock().unwrap().push(output);
    }
  }
});

for expensive in data.into_inner() {
  non_thread_safe(expensive);
}

Which today requires mutexing an &mut:

let mut data = vec![];
{
  let data_mutex = Mutex::new(&mut data);
  crossbeam::scope(|scope| {
    for input in inputs {
      let data = &data_mutex;
      scope.spawn(move || {
        let output = expensive_computation(input);
        data.lock().unwrap().push(output);
      }
    }
  });
}

for expensive in data.into_inner() {
  non_thread_safe(expensive);
}

Given Arc can be unwrapped, this would also allow the last Arc<Mutex<T>> in some concurrent context to be fully unwrapped to a T.

[Gankro]

cc @aturon

[sfackler]

Seems like just an oversight to me.

[alexcrichton]

This is a dupe of rust-lang/rfcs#1269 (although cross-repo dupes are always interesting).

The consensus is basically "this can be added as soon as someone puts in the effort".

[Gankro]

Seems like a good noobie task (upon reflection I agree with the rfc issue's assesment that this should return a poison guard).

[cristicbz]

On it!

[cristicbz]

Edit: removed since @Gankro changed original description

After #29031, this is now the tracking issue for the stabilization of the following features:

• mutex_into_inner
• mutex_get_mut
• rwlock_into_inner
• ~~rwlock_get_mut~~~

[cristicbz]

This should probably be renamed into Tracking issue for sync into_inner and get_mut or something.

[alexcrichton]

Nominating for 1.6 discussion

[alexcrichton]

🔔 This issue is now entering its cycle-long final comment period for stabilization 🔔

[aturon]

I'm in favor. Follows existing conventions, fills in a bit of missing expressiveness.

[cristicbz]

Something to consider that I didn't when I submitted the PR is whether we also want fn get_mut(&mut self) on RefCell (into_inner already exists there). In addition to consistency, I actually stumbled upon this in real code: I'm using a RefCell to reuse an allocation (cached as a member) in &self methods, but I also need use it in some of the &mut self methods.

Drawbacks: the borrow_mut / get_mut duality is bound to be confusing.

(crazy idea: it would be really awesome actually, if RefCell, Mutex etc. could somehow magically implement DerefMut without Deref. Something like a trait UniqueDeref { type Target; fn unique_deref(&mut self) -> &mut Self::Target } that would somehow prevent Deref impl-s).