sgeo/take_mut

Intended to allow taking a T from a &mut T temporarily

take_mut

This crate provides (at this time) a single function, take().

take() allows for taking T out of a &mut T, doing anything with it including consuming it, and producing another T to put back in the &mut T.

During take(), if a panic occurs, the entire process will be exited, as there's no valid T to put back into the &mut T.

Contrast with std::mem::replace(), which allows for putting a different T into a &mut T, but requiring the new T to be available before being able to consume the old T.

Example

struct Foo;
let mut foo = Foo;
take_mut::take(&mut foo, |foo| {
    // Can now consume the Foo, and provide a new value later
    drop(foo);
    // Do more stuff
    Foo // Return new Foo from closure, which goes back into the &mut Foo
});

take_mut's Issues

Use std::process::abort instead of std::process::exit

This allows debuggers to catch abnormal termination and provides better information for shells about why process quit (due to SIGABRT signal). std::process::exit is hardly one.

Use of `std::process::abort` is potentially unsound

std::process::abort might fail to terminate the program if the signal is caught and the handler longjmps away. While longjmp is a poorly supported feature in Rust, it is nevertheless something that is valid to do.

Add a variante of take() that allows returning values

In keeping with Rust's expression-oriented nature, it would be nice to have a variant of take() that allows returning some value from the closure. A sort of linear state monad.

Something like this:

pub fn take_return<T, R, F>(mut_ref: &mut T, closure: F) -> R
here
   F: FnOnce(T) -> (R, T),

   unsafe {
       let old_t = std::ptr::read(mut_ref);
       let (r, new_t) = std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| closure(old_t)))
           .unwrap_or_else(|_| std::process::abort());
       std::ptr::write(mut_ref, new_t);
       r
   }

Allow opt-in to no_std implementations

The use of std::process::catch_unwind and abort makes this crate (and all that depend on it) unusable for embedded systems.

The same guarantee the "catch_unwind or abort" mechanism gives can be achieved without that as suggested by @rkruppe in rust-lang/rfcs#2810 (comment) by placing a ZST on the stack, mem::forgetting it in the regular case and aborting in its Drop implementation.

Then, an endless_loop_on_error feature could be introduced that replaces the abort with a loop {};. This will allow take_mut to be used in no_std environments that don't have unwrapping anyway (so the endless loop will not even be ever entered). Libraries that depend on take_mut should not opt in to that feature (as they might just as well be used in std scenarios), only no_std applications should pull this in.

(Whether it is a good idea then to replace the catch_unwind with the ZST-Drop trick in general I can't tell, but it'd probably help keep the complexity of the distinction low.)