//! [`Cell<T>`] implements interior mutability by moving values in and out of the cell. That is, an
//! resource intensive (e.g. numbers), and should usually be preferred over other cell types when
//! [`RefCell<T>`] uses Rust's lifetimes to implement "dynamic borrowing", a process whereby one can
//! [`borrow_mut`](`RefCell::borrow_mut`). When these functions are called, they first verify that
//! single mutable borrow is allowed, but never both. If a borrow is attempted that would violate
//! - [`get_mut`](OnceCell::get_mut): provide a mutable reference to the inner value, only available
//! This happens implicitly by simply attempting to dereference the LazyCell to get its contents,
//! More complicated patterns that don't fit this description can be built on `OnceCell<T>` instead.
//! The more common inherited mutability, where one must have unique access to mutate a value, is
//! one of the key language elements that enables Rust to reason strongly about pointer aliasing,
//! interior mutability is something of a last resort. Since cell types enable mutation where it
//! Many shared smart pointer types, including [`Rc<T>`] and [`Arc<T>`], provide containers that can
//! "under the hood". This may be because logically the operation is immutable, but e.g., caching
//! forces the implementation to perform mutation; or because you must employ mutation to implement
//! This is simply a special - but common - case of the previous: hiding mutability for operations
//! that appear to be immutable. The [`clone`](Clone::clone) method is expected to not change the
//! source value, and is declared to take `&self`, not `&mut self`. Therefore, any mutation that
/// This function will panic if `self` and `other` are different `Cell`s that partially overlap.
/// (Using just standard library methods, it is impossible to create such partially overlapping `Cell`s.
/// However, unsafe code is allowed to e.g. create two `&Cell<[i32; 2]>` that partially overlap.)
/// unnecessary. Note that this method does not reset the borrowing state if borrows were previously leaked
/// ensure no borrows exist and then resets the state tracking shared borrows. This is relevant
/// references. The `RefCell` can be immutably borrowed again if only a smaller number of leaks
/// let b2: Result<_, (RefMut<'_, Vec<u8>>, Utf8Error)> = RefMut::try_map(b1, |v| from_utf8_mut(v));
/// If you have a reference `&T`, then normally in Rust the compiler performs optimizations based on
/// the knowledge that `&T` points to immutable data. Mutating that data, for example through an
/// `&UnsafeCell<T>` may point to data that is being mutated. This is called "interior mutability".
/// All other types that allow internal mutability, such as [`Cell<T>`] and [`RefCell<T>`], internally
/// Note that only the immutability guarantee for shared references is affected by `UnsafeCell`. The
/// uniqueness guarantee for mutable references is unaffected. There is *no* legal way to obtain
/// `UnsafeCell` does nothing to avoid data races; they are still undefined behavior. If multiple
/// [concurrent memory model]: conflicting non-synchronized accesses must be done via the APIs in
/// `*mut T` to its contents. It is up to _you_ as the abstraction designer to use that raw pointer
/// The precise Rust aliasing rules are somewhat in flux, but the main points are not contentious:
/// - If you create a safe reference with lifetime `'a` (either a `&T` or `&mut T` reference), then
/// you must not access the data in any way that contradicts that reference for the remainder of
/// `'a`. For example, this means that if you take the `*mut T` from an `UnsafeCell<T>` and cast it
/// `&mut T` reference that is released to safe code, then you must not access the data within the
/// - For both `&T` without `UnsafeCell<_>` and `&mut T`, you must also not deallocate the data
/// inside an `UnsafeCell<_>` may be deallocated during the lifetime of the reference, after the
/// last time the reference is used (dereferenced or reborrowed). Since you cannot deallocate a part
/// of what a reference points to, this means the memory an `&T` points to can be deallocated only if
/// However, whenever a `&UnsafeCell<T>` is constructed or dereferenced, it must still point to
/// 2. A `&mut T` reference may be released to safe code provided neither other `&mut T` nor `&T`
/// ok (provided you enforce the above invariants some other way), it is still undefined behavior
/// to an `Outer<UnsafeCell<T>>` type: this is not sound when the `Outer<T>` type enables [niche]
/// 64-bit platforms, but the type `Option<UnsafeCell<NonNull<u8>>>` takes up 16 bytes of space.
/// Therefore this is not a valid conversion, despite `NonNull<u8>` and `UnsafeCell<NonNull<u8>>>`
/// having the same memory layout. This is because `UnsafeCell` disables niche optimizations in
/// order to avoid its interior mutability property from spreading from `T` into the `Outer` type,
/// Here is an example showcasing how to soundly mutate the contents of an `UnsafeCell<_>` despite
/// aliasing rules; see [the type-level docs][UnsafeCell#aliasing-rules] for more discussion and
/// aliasing rules; see [the type-level docs][UnsafeCell#aliasing-rules] for more discussion and