When I can use either Cell or RefCell, which should I choose?
Solution 1:
I think it is important to take into account the other semantic differences between Cell
and RefCell
:
-
Cell
provides you values,RefCell
with references -
Cell
never panics,RefCell
can panic
Let us imagine a situation where these differences matter:
let cell = Cell::new(foo);
{
let mut value = cell.get();
// do some heavy processing on value
cell.set(value);
}
In this case, if we imagine some complex workflow with a lot of callback and that cell
is part of a global state, it is possible that the contents of cell
are modified as a side effect of the "heavy processing", and these potential changes will be lost when value
is written back in cell
.
On the other hand, a similar code using RefCell
:
let cell = RefCell::new(foo);
{
let mut_ref = cell.borrow_mut().unwrap();
// do some heavy processing on mut_ref
}
In this case, any modification of cell
as a side-effect of the "heavy processing" is forbidden, and would result into a panic. You thus are certain that the value of cell
will not change without using mut_ref
I would decide which to use depending of the semantics of the value it holds, rather than simply the Copy
trait. If both are acceptable, then Cell
is lighter and safer than the other, and thus would be preferable.
Solution 2:
You should use Cell
, if you can.
Cell
uses no runtime checking at all. All it does is an encapsulation that disallows aliasing and tells the compiler that it is an internally mutable slot. In most cases, it should compile to code that is exactly the same as if the type without cell wrapping was there.
By comparison, RefCell
uses a simple usage counter to check borrowing vs. mutable borrowing at runtime, and that check can lead to a panic at runtime if you violate for example the exclusivity of mutable borrowing. The possible panic can be an impediment to optimization.
There is at least one more difference. A Cell
will never let you get a pointer to the stored value itself. So, if you need that, a RefCell
is the only choice.
Solution 3:
TL; DR: Cell
when you can.
Long answer: Cell
and RefCell
have a similar name because they both permit the interior mutability, but they have a different purpose:
Cell
It is a wrapper around T
that forbids to share it multiple times at once: you cannot borrow immutably the inner data. This wrapper does not have any overhead, but because of this limitation, you can only do the following operations:
- Set the inner value,
- Swap the inner value with something else,
- Copy the inner value (only when
T
isCopy
able, thus).
Thanks to its limitation, the Cell
behaves like an exclusive borrow, aka a &mut T
. Therefore, it is always safe to change the inner value. To summarize:
- Advantage: no overhead
- Advantage: always mutable
- Limitation: some operations are impossible
RefCell
It is a wrapper around T
that "removes" the compile-time borrow-checks: the operations that modify the inner value take a shared reference &self
to the RefCell
. Normally, this would be unsafe, but each modifying operation firstly verify that the value was not previously borrowed. The exclusivity of a mutable borrow is verified at runtime.
To summarize:
- Limitation: a very small overhead
- Limitation: not always mutable, if it was previously mutably borrowed (beware, some operations may panic in this case)
- Advantage: you are not limited with the operations that you can do
What should you chose?
The advantages and limitations are a mirror of each other. The answer to your question is: if the limitations of Cell
do not bother you, use it, because beside this, it has only advantages. However, if you want a more flexible interior mutability, use RefCell
.