When would you be required to use Cell or RefCell? It seems like there are many other type choices that would be suitable in place of these, and the documentation warns that using RefCell
is a bit of a "last resort".
Is using these types a "code smell"? Can anyone show an example where using these types makes more sense than using another type, such as Rc
or even Box
?
Suppose you want or need to create some object of the type of your choice and dump it into an
Rc
.Now, you can easily create another
Rc
that points to the exact same object and therefore memory location:Since in Rust you may never have a mutable reference to a memory location to which any other reference exists, these
Rc
containers can never be modified again.So, what if you wanted to be able to modify those objects and have multiple
Rc
pointing to one and the same object?This is the issue that
Cell
andRefCell
solve. The solution is called "interior mutability", and it means that Rust's aliasing rules are enforced at runtime instead of compile-time.Back to our original example:
To get a mutable reference to your type, you use
borrow_mut
on theRefCell
.In case you already borrowed the value your
Rc
s point to either mutably or non-mutably, theborrow_mut
function will panic, and therefore enforce Rust's aliasing rules.Rc<RefCell<T>>
is just one example forRefCell
, there are many other legitimate uses. But the documentation is right. If there is another way, use it, because the compiler cannot help you reason aboutRefCell
s.It is not entirely correct to ask when
Cell
orRefCell
should be used overBox
andRc
because these types solve different problems. Indeed, more often than notRefCell
is used together withRc
in order to provide mutability with shared ownership. So yes, use cases forCell
andRefCell
are entirely dependent on the mutability requirements in your code.Interior and exterior mutability are very nicely explained in the official Rust book, in the designated chapter on mutability. External mutability is very closely tied to the ownership model, and mostly when we say that something is mutable or immutable we mean exactly the external mutability. Another name for external mutability is inherited mutability, which probably explains the concept more clearly: this kind of mutability is defined by the owner of the data and inherited to everything you can reach from the owner. For example, if your variable of a structural type is mutable, so are all fields of the structure in the variable:
Inherited mutability also defines which kinds of references you can get out of the value:
Sometimes, however, inherited mutability is not enough. The canonical example is reference-counted pointer, called
Rc
in Rust. The following code is entirely valid:At the first glance it is not clear how mutability is related to this, but recall that reference-counted pointers are called so because they contain an internal reference counter which is modified when a reference is duplicated (
clone()
in Rust) and destroyed (goes out of scope inRust
). HenceRc
has to modify itself even though it is stored inside a non-mut
variable.This is achieved via internal mutability. There are special types in the standard library, the most basic of them being
UnsafeCell
, which allow one to work around the rules of external mutability and mutate something even if it is stored (transitively) in a non-mut
variable.Another way to say that something has internal mutability is that this something can be modified through a
&
-reference - that is, if you have a value of type&T
and you can modify the state ofT
which it points at, thenT
has internal mutability.For example,
Cell
can containCopy
data and it can be mutated even if it is stored in non-mut
location:RefCell
can contain non-Copy
data and it can give you&mut
pointers to its contained value, and absence of aliasing is checked at runtime. This is all explained in detail on their documentation pages.As it turned out, in overwhelming number of situations you can easily go with external mutability only. Most of existing high-level code in Rust is written that way. Sometimes, however, internal mutability is unavoidable or makes the code much clearer. One example,
Rc
implementation, is already described above. Another one is when you need shared mutable ownership (that is, you need to access and modify the same value from different parts of your code) - this is usually achieved viaRc<RefCell<T>>
, because it can't be done with references alone. Even another example isArc<Mutex<T>>
,Mutex
being another type for internal mutability which is also safe to use across threads.So, as you can see,
Cell
andRefCell
are not replacements forRc
orBox
; they solve the task of providing you mutability somewhere where it is not allowed by default. You can write your code without using them at all; and if you get into a situation when you would need them, you will know it.Cell
s andRefCell
s are not code smell; the only reason whey they are described as "last resort" is that they move the task of checking mutability and aliasing rules from the compiler to the runtime code, as in case withRefCell
: you can't have two&mut
s pointing to the same data at the same time, this is statically enforced by the compiler, but withRefCell
s you can ask the sameRefCell
to give you as much&mut
s as you like - except that if you do it more than once it will panic at you, enforcing aliasing rules at runtime. Panics are arguably worse than compilation errors because you can only find errors causing them at runtime rather than at compilation time. Sometimes, however, the static analyzer in the compiler is too restrictive, and you indeed do need to "work around" it.No,
Cell
andRefCell
aren't "code smells". Normally, mutability is inherited, that is you can mutate a field or a part of a data structure if and only if you have exclusive access to of the whole data structure, and hence you can opt into mutability at that level withmut
(i.e.,foo.x
inherits its mutability or lack thereof fromfoo
). This is a very powerful pattern and should be used whenever it works well (which is surprisingly often). But it's not expressive enough for all code everywhere.Box
andRc
have nothing to do with this. Like almost all other types, they respect inherited mutability: you can mutate the contents of aBox
if you have exclusive, mutable access to theBox
(because that means you have exclusive access to the contents, too). Conversely, you can never get a&mut
to the contents of anRc
because by its natureRc
is shared (i.e. there can be multipleRc
s referring to the same data).One common case of
Cell
orRefCell
is that you need to share mutable data between several places. Having two&mut
references to the same data is normally not allowed (and for good reason!). However, sometimes you need it, and the cell types enable doing it safely.This could be done via the common combination of
Rc<RefCell<T>>
, which allows the data to stick around for as long as anyone uses it and allows everyone (but only one at a time!) to mutate it. Or it could be as simple as&Cell<i32>
(even if the cell is wrapped in a more meaningful type). The latter is also commonly used for internal, private, mutable state like reference counts.The documentation actually has several examples of where you'd use
Cell
orRefCell
. A good example is actuallyRc
itself. When creating a newRc
, the reference count must be increased, but the reference count is shared between allRc
s, so, by inherited mutability, this couldn't possibly work.Rc
practically has to use aCell
.A good guideline is to try writing as much code as possible without cell types, but using them when it hurts too much without them. In some cases, there is a good solution without cells, and, with experience, you'll be able to find those when you previously missed them, but there will always be things that just aren't possible without them.