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 https://github.com/rust-lang/rfcs/issues/2810#issuecomment-559469938 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.)
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 https://github.com/rust-lang/rfcs/issues/2810#issuecomment-559469938 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 aloop {};
. This will allow take_mut to be used inno_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.)