`&T`, `&mut T`, `Pin<&mut T>` and `&Cell<T>`: Ways of Borrowing a `T`

1

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.

2

This feels like an interesting idea for a fully-featured article on a technical blog, exploring all the ins and out of the different ways to borrow/mutate/architect your code while taking into consideration the different ways in which you may (not) want to access the underlying T; which you could share all over the different socials/forums like this one, and I doubt many people would heavily object.

Without any context, though - it does feel just a little bit .. off? There's a bit of an LLM feel to it, with no concrete examples or practical insight (in terms of which exact problem it helps/ed you or anyone else to address) in particular, making it come off as a more of an extract from a research paper than any typical ... "post" out there, I guess. Are you sharing this to get some feedback? Validation? To help people choose the right way to borrow their T's? To invite some kind of discussion, maybe?

As a newly identified reader, I did attempt to consider the very concept the author has considered worthy of my... consideration? - though I'm still just a tiny bit confused with regards to the exact choice of wording for this particular use case. "Does the concept of Interior Mutability make up separate counterparts of the primitive references?" - is that the question I'm invited to consider? Because I'm not certain my mind is equipped with a semantic parser advanced enough to comprehend the full meaning encoded in that sequence of English lexemes, I'm afraid..

That's actually quite neat, might use it one day myself.

3

i think i should be safe for structs and arrays but not for enums because changing variant would invalidate all the projected Cells.

an easy way to prove it would be to make something like this

struct Struct{
field:i32
}
struct FakeCell{
struct:a Cell<Struct>
}

impl FackeCell{
 pub fn get(&self){
 self.struct.get().field
}
impl FackeCell<'a>{
 pub fn set(&self,field:i32){
 let struct=self.struct.get();
 struct.field=field
self.struct.set(field)
}
}
4

Another thing that does also support transparent from_mut creation is the “ghost cell” concept: tagging both the cell as well as an access token kind of object with the same invariant lifetime parameter to connect them through the type system (/ borrow checker), and then you manage your access through that access token. Soundness is achieved by additionally making it so that the tokens can only be created each with their own unique lifetime.

There’s also the qcell crate which offers a variety of types, some being transparent wrappers too (infact that’s all except for QCell itself[1]), too; and the LCell type there is very similar to ghost-cell. The crate doesn’t include any from_mut APIs but that might have just been an oversight (I don’t think there’d be a soundness issue with that idea).

In particular, it has one that uses a marker type and run-time checks that only a single “owner” can be created for each marker time (though some global HashSet tracking all existing [in-use] markers that owners have been created for). And TLCell which works like TCell but saves the info on which owners exist thread-locally, and correspondingly has to make the cell type non-Sync though! (Unlike std’s Cell you can access the contained value by-reference when the cell is “unlocked” by presenting a borrow of the owner.)

  1. that one uses run-time integer tags to identify which “owner” each cell belongs to ↩︎