Disclaimer: This post is crossposted from a post of the same name in the unofficial Rust subreddit made by me, because I was baselessly accused of making an AI-generated post, so I apologize for the redundancy. I advise readers not to brigade other community and focus and ideas I propose, and politely point out if there is something wrong with my post - I kept the contents of the post the same for this purpose. I know that the last sentence of the post sounds AI-Generated, but I was just aggressively using passive language, and do not know how to word it better. Thank you for your attention.

Interior Mutability is usually considered to be an inherent property to a type - a type with interior mutability has very different invariants from a type that does not, and there are varying degrees of interior mutability too. And so it's not often thought that a type can be arbitrary borrowed as interior mutable; for example a T can't be borrowed as RefCell<T> because they do not have the same size - but Cell<T> (and UnsafeCell<T>) is special in this regard.

The key sparking this discussion is that a &Cell<T> can be obtained from a &mut T using Cell::from_mut - which can easily be proven to be safe.

This also works for slices (and arrays): a &[Cell<T>] can be obtained from a &mut [T] using Cell::from_mut and Cell::as_slice_of_cells. You may be surprised that Cell also accepts unsized types - these can be obtaining using an unsizing coercion on a reference - though they are not useful by themselves so they may as well not exist.

So any sliceable type like Vec<T> can be borrowed as copyable references to a slice that can be edited by multiple consumers - though not by multiple threads. As a consequence, unlike &mut [T], it is possible for &[Cell<T>]s to point to overlapping memory, like how two &Cell<T>s can point to the same object.

So why is Cell rarely brought up at all? Because there are two - and only two - things you can do with a &Cell<T>:

• Swap values between two &Cell<T> using Cell::swap.
• Copy the value behind &Cell<T> using Cell::get, but only if T: Copy.

...

That's it.

In fact, not only is &Cell<T> limited in behavior, it also lacks many capabilities of &T and &mut T, and is not treated specially by the compiler either:

• They can not be projected to an inner field because there is no first-class language support.
  • Projection is a casting a &Cell<Struct> given struct Struct(A, B) into a &Cell<InnerField> like &Cell<A> or &Cell<B>.
  • Do you know if it is safe to project &Cell<Struct>?
  • Because it is safe to cast a &Cell<[T; N]> into &[Cell<T>; N] using Cell::as_array_of_cells, so I'm not sure if it is safe to do so for structs and write a safe Cell projection macro.
• Cell is not a fundamental type like &T, &mut T, Box<T>, Pin<Ptr> (issue for fundamental attribute).
• Cell cannot be used as self receivers like fundamental types, Rc<T> and Arc<T> (issue for arbitrary self types).
• &mut T implicitly casts to &T, but not to &Cell<T>.

But unlike Box<T>, Rc<T> and Arc<T>, &Cell<T> can be obtained from &mut T, and so is independent of how T is stored.

Since Cell does not implement synchronization, it never implements Sync. Adding a lock to the type increases its size and it will cease to be a Cell.

A hypothetical SyncCell<T> would provide the same APIs as Cell<T> - including projection, if it is truly safe, but all accesses will be synchronized using an array of global locks to minimize contention. I do not know if there is a crate for this type yet.

The AtomicCell<T> in crate crossbeam also synchronizes using an array of global locks, but will transmute to their bespoke atomic implementation that supports uninitialized memory if the size and alignment of T match one of them (atomics in core also have nightly from_mut method). But unlike SyncCell<T>, projection is not safe because atomic access of different sizes are probably incompatible. While the API for from_mut has been removed, the author confirmed that re-adding the API is safe.

In conclusion, theoretically there are six mutually exclusive way of borrowing a T: &T, &mut T, Pin<&mut T>, &Cell<T>, &SyncCell<T> and &AtomicCell<T>, and projection support could theoretically be added for pins and cells (Pin<Ptr> has the pin-project crate, which is also maintained by the same author). This post invites readers to consider if the concept of Interior Mutability is not only a property of a type that must be decided beforehand, but also makes up separate counterparts of primitive references.