Skip to main content

MutableExt

rx_rust::utils::mutable

Trait MutableExt 

Source 
pub trait MutableExt: MutableHelper {
    // Provided methods
    fn clone_value(&self) -> Self::Value
       where Self::Value: Clone { ... }
    fn replace_value(&self, value: Self::Value) -> Self::Value { ... }
    fn take_value(&self) -> Self::Value
       where Self::Value: Default { ... }
}
Expand description

The handful of one-shot operations that cover most uses of a Mutable.

Each of them takes the lock exactly once and hands every value it produces back to the caller, so the value is used — and dropped — after the lock has been released.

The _value suffixes keep these names clear of the inherent methods of the two backends: RefCell::take already exists, and Mutex::{get_cloned, set} exist behind the unstable lock_value_accessors feature. An inherent method wins method resolution over a trait one, so a colliding name would silently bypass the re-entrancy check on one of the two backends.

Provided Methods§

Source

fn clone_value(&self) -> Self::Value
where Self::Value: Clone,

Clones the contained value.

Source

fn replace_value(&self, value: Self::Value) -> Self::Value

Stores value and returns the replaced one, leaving it to the caller to drop it outside the lock.

Source

fn take_value(&self) -> Self::Value
where Self::Value: Default,

Takes the contained value out, leaving the default in its place.

For a Mutable<Option<T>> this is Option::take, and for a Mutable<Vec<T>> it is the deadlock-free replacement for clear: the elements are dropped by the caller instead of under the lock.

This is the shape to reach for whenever what follows is anything the crate does not own — Observer::on_next, Observer::on_termination, Disposable::dispose — because all of them can re-enter the very lock they were reached through. slot.take_value().map(f) runs f with the lock already released.

Dyn Compatibility§

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors§