626 lines
35 KiB
HTML
626 lines
35 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="en">
|
||
<head>
|
||
<meta charset="UTF-8">
|
||
<title>RefCell<T> and the Interior Mutability Pattern</title>
|
||
</head>
|
||
<body>
|
||
<h2 id="refcellt-and-the-interior-mutability-pattern"><a class="header" href="#refcellt-and-the-interior-mutability-pattern"><code>RefCell<T></code> and the Interior Mutability Pattern</a></h2>
|
||
<p><em>Interior mutability</em> is a design pattern in Rust that allows you to mutate
|
||
data even when there are immutable references to that data; normally, this
|
||
action is disallowed by the borrowing rules. To mutate data, the pattern uses
|
||
<code>unsafe</code> code inside a data structure to bend Rust’s usual rules that govern
|
||
mutation and borrowing. Unsafe code indicates to the compiler that we’re
|
||
checking the rules manually instead of relying on the compiler to check them
|
||
for us; we will discuss unsafe code more in Chapter 20.</p>
|
||
<p>We can use types that use the interior mutability pattern only when we can
|
||
ensure that the borrowing rules will be followed at runtime, even though the
|
||
compiler can’t guarantee that. The <code>unsafe</code> code involved is then wrapped in a
|
||
safe API, and the outer type is still immutable.</p>
|
||
<p>Let’s explore this concept by looking at the <code>RefCell<T></code> type that follows the
|
||
interior mutability pattern.</p>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="enforcing-borrowing-rules-at-runtime-with-refcellt"></a></p>
|
||
<h3 id="enforcing-borrowing-rules-at-runtime"><a class="header" href="#enforcing-borrowing-rules-at-runtime">Enforcing Borrowing Rules at Runtime</a></h3>
|
||
<p>Unlike <code>Rc<T></code>, the <code>RefCell<T></code> type represents single ownership over the data
|
||
it holds. So, what makes <code>RefCell<T></code> different from a type like <code>Box<T></code>?
|
||
Recall the borrowing rules you learned in Chapter 4:</p>
|
||
<ul>
|
||
<li>At any given time, you can have <em>either</em> one mutable reference or any number
|
||
of immutable references (but not both).</li>
|
||
<li>References must always be valid.</li>
|
||
</ul>
|
||
<p>With references and <code>Box<T></code>, the borrowing rules’ invariants are enforced at
|
||
compile time. With <code>RefCell<T></code>, these invariants are enforced <em>at runtime</em>.
|
||
With references, if you break these rules, you’ll get a compiler error. With
|
||
<code>RefCell<T></code>, if you break these rules, your program will panic and exit.</p>
|
||
<p>The advantages of checking the borrowing rules at compile time are that errors
|
||
will be caught sooner in the development process, and there is no impact on
|
||
runtime performance because all the analysis is completed beforehand. For those
|
||
reasons, checking the borrowing rules at compile time is the best choice in the
|
||
majority of cases, which is why this is Rust’s default.</p>
|
||
<p>The advantage of checking the borrowing rules at runtime instead is that
|
||
certain memory-safe scenarios are then allowed, where they would’ve been
|
||
disallowed by the compile-time checks. Static analysis, like the Rust compiler,
|
||
is inherently conservative. Some properties of code are impossible to detect by
|
||
analyzing the code: The most famous example is the Halting Problem, which is
|
||
beyond the scope of this book but is an interesting topic to research.</p>
|
||
<p>Because some analysis is impossible, if the Rust compiler can’t be sure the
|
||
code complies with the ownership rules, it might reject a correct program; in
|
||
this way, it’s conservative. If Rust accepted an incorrect program, users
|
||
wouldn’t be able to trust the guarantees Rust makes. However, if Rust rejects a
|
||
correct program, the programmer will be inconvenienced, but nothing
|
||
catastrophic can occur. The <code>RefCell<T></code> type is useful when you’re sure your
|
||
code follows the borrowing rules but the compiler is unable to understand and
|
||
guarantee that.</p>
|
||
<p>Similar to <code>Rc<T></code>, <code>RefCell<T></code> is only for use in single-threaded scenarios
|
||
and will give you a compile-time error if you try using it in a multithreaded
|
||
context. We’ll talk about how to get the functionality of <code>RefCell<T></code> in a
|
||
multithreaded program in Chapter 16.</p>
|
||
<p>Here is a recap of the reasons to choose <code>Box<T></code>, <code>Rc<T></code>, or <code>RefCell<T></code>:</p>
|
||
<ul>
|
||
<li><code>Rc<T></code> enables multiple owners of the same data; <code>Box<T></code> and <code>RefCell<T></code>
|
||
have single owners.</li>
|
||
<li><code>Box<T></code> allows immutable or mutable borrows checked at compile time; <code>Rc<T></code>
|
||
allows only immutable borrows checked at compile time; <code>RefCell<T></code> allows
|
||
immutable or mutable borrows checked at runtime.</li>
|
||
<li>Because <code>RefCell<T></code> allows mutable borrows checked at runtime, you can
|
||
mutate the value inside the <code>RefCell<T></code> even when the <code>RefCell<T></code> is
|
||
immutable.</li>
|
||
</ul>
|
||
<p>Mutating the value inside an immutable value is the interior mutability
|
||
pattern. Let’s look at a situation in which interior mutability is useful and
|
||
examine how it’s possible.</p>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="interior-mutability-a-mutable-borrow-to-an-immutable-value"></a></p>
|
||
<h3 id="using-interior-mutability"><a class="header" href="#using-interior-mutability">Using Interior Mutability</a></h3>
|
||
<p>A consequence of the borrowing rules is that when you have an immutable value,
|
||
you can’t borrow it mutably. For example, this code won’t compile:</p>
|
||
<pre><code class="language-rust ignore does_not_compile">fn main() {
|
||
let x = 5;
|
||
let y = &mut x;
|
||
}</code></pre>
|
||
<p>If you tried to compile this code, you’d get the following error:</p>
|
||
<pre><code class="language-console">$ cargo run
|
||
Compiling borrowing v0.1.0 (file:///projects/borrowing)
|
||
error[E0596]: cannot borrow `x` as mutable, as it is not declared as mutable
|
||
--> src/main.rs:3:13
|
||
|
|
||
3 | let y = &mut x;
|
||
| ^^^^^^ cannot borrow as mutable
|
||
|
|
||
help: consider changing this to be mutable
|
||
|
|
||
2 | let mut x = 5;
|
||
| +++
|
||
|
||
For more information about this error, try `rustc --explain E0596`.
|
||
error: could not compile `borrowing` (bin "borrowing") due to 1 previous error
|
||
</code></pre>
|
||
<p>However, there are situations in which it would be useful for a value to mutate
|
||
itself in its methods but appear immutable to other code. Code outside the
|
||
value’s methods would not be able to mutate the value. Using <code>RefCell<T></code> is
|
||
one way to get the ability to have interior mutability, but <code>RefCell<T></code>
|
||
doesn’t get around the borrowing rules completely: The borrow checker in the
|
||
compiler allows this interior mutability, and the borrowing rules are checked
|
||
at runtime instead. If you violate the rules, you’ll get a <code>panic!</code> instead of
|
||
a compiler error.</p>
|
||
<p>Let’s work through a practical example where we can use <code>RefCell<T></code> to mutate
|
||
an immutable value and see why that is useful.</p>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="a-use-case-for-interior-mutability-mock-objects"></a></p>
|
||
<h4 id="testing-with-mock-objects"><a class="header" href="#testing-with-mock-objects">Testing with Mock Objects</a></h4>
|
||
<p>Sometimes during testing a programmer will use a type in place of another type,
|
||
in order to observe particular behavior and assert that it’s implemented
|
||
correctly. This placeholder type is called a <em>test double</em>. Think of it in the
|
||
sense of a stunt double in filmmaking, where a person steps in and substitutes
|
||
for an actor to do a particularly tricky scene. Test doubles stand in for other
|
||
types when we’re running tests. <em>Mock objects</em> are specific types of test
|
||
doubles that record what happens during a test so that you can assert that the
|
||
correct actions took place.</p>
|
||
<p>Rust doesn’t have objects in the same sense as other languages have objects,
|
||
and Rust doesn’t have mock object functionality built into the standard library
|
||
as some other languages do. However, you can definitely create a struct that
|
||
will serve the same purposes as a mock object.</p>
|
||
<p>Here’s the scenario we’ll test: We’ll create a library that tracks a value
|
||
against a maximum value and sends messages based on how close to the maximum
|
||
value the current value is. This library could be used to keep track of a
|
||
user’s quota for the number of API calls they’re allowed to make, for example.</p>
|
||
<p>Our library will only provide the functionality of tracking how close to the
|
||
maximum a value is and what the messages should be at what times. Applications
|
||
that use our library will be expected to provide the mechanism for sending the
|
||
messages: The application could show the message to the user directly, send an
|
||
email, send a text message, or do something else. The library doesn’t need to
|
||
know that detail. All it needs is something that implements a trait we’ll
|
||
provide, called <code>Messenger</code>. Listing 15-20 shows the library code.</p>
|
||
<figure class="listing" id="listing-15-20">
|
||
<span class="file-name">Filename: src/lib.rs</span>
|
||
<pre><code class="language-rust noplayground">pub trait Messenger {
|
||
fn send(&self, msg: &str);
|
||
}
|
||
|
||
pub struct LimitTracker<'a, T: Messenger> {
|
||
messenger: &'a T,
|
||
value: usize,
|
||
max: usize,
|
||
}
|
||
|
||
impl<'a, T> LimitTracker<'a, T>
|
||
where
|
||
T: Messenger,
|
||
{
|
||
pub fn new(messenger: &'a T, max: usize) -> LimitTracker<'a, T> {
|
||
LimitTracker {
|
||
messenger,
|
||
value: 0,
|
||
max,
|
||
}
|
||
}
|
||
|
||
pub fn set_value(&mut self, value: usize) {
|
||
self.value = value;
|
||
|
||
let percentage_of_max = self.value as f64 / self.max as f64;
|
||
|
||
if percentage_of_max >= 1.0 {
|
||
self.messenger.send("Error: You are over your quota!");
|
||
} else if percentage_of_max >= 0.9 {
|
||
self.messenger
|
||
.send("Urgent warning: You've used up over 90% of your quota!");
|
||
} else if percentage_of_max >= 0.75 {
|
||
self.messenger
|
||
.send("Warning: You've used up over 75% of your quota!");
|
||
}
|
||
}
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-15-20">Listing 15-20</a>: A library to keep track of how close a value is to a maximum value and warn when the value is at certain levels</figcaption>
|
||
</figure>
|
||
<p>One important part of this code is that the <code>Messenger</code> trait has one method
|
||
called <code>send</code> that takes an immutable reference to <code>self</code> and the text of the
|
||
message. This trait is the interface our mock object needs to implement so that
|
||
the mock can be used in the same way a real object is. The other important part
|
||
is that we want to test the behavior of the <code>set_value</code> method on the
|
||
<code>LimitTracker</code>. We can change what we pass in for the <code>value</code> parameter, but
|
||
<code>set_value</code> doesn’t return anything for us to make assertions on. We want to be
|
||
able to say that if we create a <code>LimitTracker</code> with something that implements
|
||
the <code>Messenger</code> trait and a particular value for <code>max</code>, the messenger is told
|
||
to send the appropriate messages when we pass different numbers for <code>value</code>.</p>
|
||
<p>We need a mock object that, instead of sending an email or text message when we
|
||
call <code>send</code>, will only keep track of the messages it’s told to send. We can
|
||
create a new instance of the mock object, create a <code>LimitTracker</code> that uses the
|
||
mock object, call the <code>set_value</code> method on <code>LimitTracker</code>, and then check that
|
||
the mock object has the messages we expect. Listing 15-21 shows an attempt to
|
||
implement a mock object to do just that, but the borrow checker won’t allow it.</p>
|
||
<figure class="listing" id="listing-15-21">
|
||
<span class="file-name">Filename: src/lib.rs</span>
|
||
<pre><code class="language-rust ignore does_not_compile"><span class="boring">pub trait Messenger {
|
||
</span><span class="boring"> fn send(&self, msg: &str);
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">pub struct LimitTracker<'a, T: Messenger> {
|
||
</span><span class="boring"> messenger: &'a T,
|
||
</span><span class="boring"> value: usize,
|
||
</span><span class="boring"> max: usize,
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">impl<'a, T> LimitTracker<'a, T>
|
||
</span><span class="boring">where
|
||
</span><span class="boring"> T: Messenger,
|
||
</span><span class="boring">{
|
||
</span><span class="boring"> pub fn new(messenger: &'a T, max: usize) -> LimitTracker<'a, T> {
|
||
</span><span class="boring"> LimitTracker {
|
||
</span><span class="boring"> messenger,
|
||
</span><span class="boring"> value: 0,
|
||
</span><span class="boring"> max,
|
||
</span><span class="boring"> }
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> pub fn set_value(&mut self, value: usize) {
|
||
</span><span class="boring"> self.value = value;
|
||
</span><span class="boring">
|
||
</span><span class="boring"> let percentage_of_max = self.value as f64 / self.max as f64;
|
||
</span><span class="boring">
|
||
</span><span class="boring"> if percentage_of_max >= 1.0 {
|
||
</span><span class="boring"> self.messenger.send("Error: You are over your quota!");
|
||
</span><span class="boring"> } else if percentage_of_max >= 0.9 {
|
||
</span><span class="boring"> self.messenger
|
||
</span><span class="boring"> .send("Urgent warning: You've used up over 90% of your quota!");
|
||
</span><span class="boring"> } else if percentage_of_max >= 0.75 {
|
||
</span><span class="boring"> self.messenger
|
||
</span><span class="boring"> .send("Warning: You've used up over 75% of your quota!");
|
||
</span><span class="boring"> }
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span>#[cfg(test)]
|
||
mod tests {
|
||
use super::*;
|
||
|
||
struct MockMessenger {
|
||
sent_messages: Vec<String>,
|
||
}
|
||
|
||
impl MockMessenger {
|
||
fn new() -> MockMessenger {
|
||
MockMessenger {
|
||
sent_messages: vec![],
|
||
}
|
||
}
|
||
}
|
||
|
||
impl Messenger for MockMessenger {
|
||
fn send(&self, message: &str) {
|
||
self.sent_messages.push(String::from(message));
|
||
}
|
||
}
|
||
|
||
#[test]
|
||
fn it_sends_an_over_75_percent_warning_message() {
|
||
let mock_messenger = MockMessenger::new();
|
||
let mut limit_tracker = LimitTracker::new(&mock_messenger, 100);
|
||
|
||
limit_tracker.set_value(80);
|
||
|
||
assert_eq!(mock_messenger.sent_messages.len(), 1);
|
||
}
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-15-21">Listing 15-21</a>: An attempt to implement a <code>MockMessenger</code> that isn’t allowed by the borrow checker</figcaption>
|
||
</figure>
|
||
<p>This test code defines a <code>MockMessenger</code> struct that has a <code>sent_messages</code>
|
||
field with a <code>Vec</code> of <code>String</code> values to keep track of the messages it’s told
|
||
to send. We also define an associated function <code>new</code> to make it convenient to
|
||
create new <code>MockMessenger</code> values that start with an empty list of messages. We
|
||
then implement the <code>Messenger</code> trait for <code>MockMessenger</code> so that we can give a
|
||
<code>MockMessenger</code> to a <code>LimitTracker</code>. In the definition of the <code>send</code> method, we
|
||
take the message passed in as a parameter and store it in the <code>MockMessenger</code>
|
||
list of <code>sent_messages</code>.</p>
|
||
<p>In the test, we’re testing what happens when the <code>LimitTracker</code> is told to set
|
||
<code>value</code> to something that is more than 75 percent of the <code>max</code> value. First, we
|
||
create a new <code>MockMessenger</code>, which will start with an empty list of messages.
|
||
Then, we create a new <code>LimitTracker</code> and give it a reference to the new
|
||
<code>MockMessenger</code> and a <code>max</code> value of <code>100</code>. We call the <code>set_value</code> method on
|
||
the <code>LimitTracker</code> with a value of <code>80</code>, which is more than 75 percent of 100.
|
||
Then, we assert that the list of messages that the <code>MockMessenger</code> is keeping
|
||
track of should now have one message in it.</p>
|
||
<p>However, there’s one problem with this test, as shown here:</p>
|
||
<pre><code class="language-console">$ cargo test
|
||
Compiling limit-tracker v0.1.0 (file:///projects/limit-tracker)
|
||
error[E0596]: cannot borrow `self.sent_messages` as mutable, as it is behind a `&` reference
|
||
--> src/lib.rs:58:13
|
||
|
|
||
58 | self.sent_messages.push(String::from(message));
|
||
| ^^^^^^^^^^^^^^^^^^ `self` is a `&` reference, so the data it refers to cannot be borrowed as mutable
|
||
|
|
||
help: consider changing this to be a mutable reference in the `impl` method and the `trait` definition
|
||
|
|
||
2 ~ fn send(&mut self, msg: &str);
|
||
3 | }
|
||
...
|
||
56 | impl Messenger for MockMessenger {
|
||
57 ~ fn send(&mut self, message: &str) {
|
||
|
|
||
|
||
For more information about this error, try `rustc --explain E0596`.
|
||
error: could not compile `limit-tracker` (lib test) due to 1 previous error
|
||
</code></pre>
|
||
<p>We can’t modify the <code>MockMessenger</code> to keep track of the messages, because the
|
||
<code>send</code> method takes an immutable reference to <code>self</code>. We also can’t take the
|
||
suggestion from the error text to use <code>&mut self</code> in both the <code>impl</code> method and
|
||
the trait definition. We do not want to change the <code>Messenger</code> trait solely for
|
||
the sake of testing. Instead, we need to find a way to make our test code work
|
||
correctly with our existing design.</p>
|
||
<p>This is a situation in which interior mutability can help! We’ll store the
|
||
<code>sent_messages</code> within a <code>RefCell<T></code>, and then the <code>send</code> method will be able
|
||
to modify <code>sent_messages</code> to store the messages we’ve seen. Listing 15-22 shows
|
||
what that looks like.</p>
|
||
<figure class="listing" id="listing-15-22">
|
||
<span class="file-name">Filename: src/lib.rs</span>
|
||
<pre><code class="language-rust noplayground"><span class="boring">pub trait Messenger {
|
||
</span><span class="boring"> fn send(&self, msg: &str);
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">pub struct LimitTracker<'a, T: Messenger> {
|
||
</span><span class="boring"> messenger: &'a T,
|
||
</span><span class="boring"> value: usize,
|
||
</span><span class="boring"> max: usize,
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">impl<'a, T> LimitTracker<'a, T>
|
||
</span><span class="boring">where
|
||
</span><span class="boring"> T: Messenger,
|
||
</span><span class="boring">{
|
||
</span><span class="boring"> pub fn new(messenger: &'a T, max: usize) -> LimitTracker<'a, T> {
|
||
</span><span class="boring"> LimitTracker {
|
||
</span><span class="boring"> messenger,
|
||
</span><span class="boring"> value: 0,
|
||
</span><span class="boring"> max,
|
||
</span><span class="boring"> }
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> pub fn set_value(&mut self, value: usize) {
|
||
</span><span class="boring"> self.value = value;
|
||
</span><span class="boring">
|
||
</span><span class="boring"> let percentage_of_max = self.value as f64 / self.max as f64;
|
||
</span><span class="boring">
|
||
</span><span class="boring"> if percentage_of_max >= 1.0 {
|
||
</span><span class="boring"> self.messenger.send("Error: You are over your quota!");
|
||
</span><span class="boring"> } else if percentage_of_max >= 0.9 {
|
||
</span><span class="boring"> self.messenger
|
||
</span><span class="boring"> .send("Urgent warning: You've used up over 90% of your quota!");
|
||
</span><span class="boring"> } else if percentage_of_max >= 0.75 {
|
||
</span><span class="boring"> self.messenger
|
||
</span><span class="boring"> .send("Warning: You've used up over 75% of your quota!");
|
||
</span><span class="boring"> }
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span>#[cfg(test)]
|
||
mod tests {
|
||
use super::*;
|
||
use std::cell::RefCell;
|
||
|
||
struct MockMessenger {
|
||
sent_messages: RefCell<Vec<String>>,
|
||
}
|
||
|
||
impl MockMessenger {
|
||
fn new() -> MockMessenger {
|
||
MockMessenger {
|
||
sent_messages: RefCell::new(vec![]),
|
||
}
|
||
}
|
||
}
|
||
|
||
impl Messenger for MockMessenger {
|
||
fn send(&self, message: &str) {
|
||
self.sent_messages.borrow_mut().push(String::from(message));
|
||
}
|
||
}
|
||
|
||
#[test]
|
||
fn it_sends_an_over_75_percent_warning_message() {
|
||
// --snip--
|
||
<span class="boring"> let mock_messenger = MockMessenger::new();
|
||
</span><span class="boring"> let mut limit_tracker = LimitTracker::new(&mock_messenger, 100);
|
||
</span><span class="boring">
|
||
</span><span class="boring"> limit_tracker.set_value(80);
|
||
</span>
|
||
assert_eq!(mock_messenger.sent_messages.borrow().len(), 1);
|
||
}
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-15-22">Listing 15-22</a>: Using <code>RefCell<T></code> to mutate an inner value while the outer value is considered immutable</figcaption>
|
||
</figure>
|
||
<p>The <code>sent_messages</code> field is now of type <code>RefCell<Vec<String>></code> instead of
|
||
<code>Vec<String></code>. In the <code>new</code> function, we create a new <code>RefCell<Vec<String>></code>
|
||
instance around the empty vector.</p>
|
||
<p>For the implementation of the <code>send</code> method, the first parameter is still an
|
||
immutable borrow of <code>self</code>, which matches the trait definition. We call
|
||
<code>borrow_mut</code> on the <code>RefCell<Vec<String>></code> in <code>self.sent_messages</code> to get a
|
||
mutable reference to the value inside the <code>RefCell<Vec<String>></code>, which is the
|
||
vector. Then, we can call <code>push</code> on the mutable reference to the vector to keep
|
||
track of the messages sent during the test.</p>
|
||
<p>The last change we have to make is in the assertion: To see how many items are
|
||
in the inner vector, we call <code>borrow</code> on the <code>RefCell<Vec<String>></code> to get an
|
||
immutable reference to the vector.</p>
|
||
<p>Now that you’ve seen how to use <code>RefCell<T></code>, let’s dig into how it works!</p>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="keeping-track-of-borrows-at-runtime-with-refcellt"></a></p>
|
||
<h4 id="tracking-borrows-at-runtime"><a class="header" href="#tracking-borrows-at-runtime">Tracking Borrows at Runtime</a></h4>
|
||
<p>When creating immutable and mutable references, we use the <code>&</code> and <code>&mut</code>
|
||
syntax, respectively. With <code>RefCell<T></code>, we use the <code>borrow</code> and <code>borrow_mut</code>
|
||
methods, which are part of the safe API that belongs to <code>RefCell<T></code>. The
|
||
<code>borrow</code> method returns the smart pointer type <code>Ref<T></code>, and <code>borrow_mut</code>
|
||
returns the smart pointer type <code>RefMut<T></code>. Both types implement <code>Deref</code>, so we
|
||
can treat them like regular references.</p>
|
||
<p>The <code>RefCell<T></code> keeps track of how many <code>Ref<T></code> and <code>RefMut<T></code> smart
|
||
pointers are currently active. Every time we call <code>borrow</code>, the <code>RefCell<T></code>
|
||
increases its count of how many immutable borrows are active. When a <code>Ref<T></code>
|
||
value goes out of scope, the count of immutable borrows goes down by 1. Just
|
||
like the compile-time borrowing rules, <code>RefCell<T></code> lets us have many immutable
|
||
borrows or one mutable borrow at any point in time.</p>
|
||
<p>If we try to violate these rules, rather than getting a compiler error as we
|
||
would with references, the implementation of <code>RefCell<T></code> will panic at
|
||
runtime. Listing 15-23 shows a modification of the implementation of <code>send</code> in
|
||
Listing 15-22. We’re deliberately trying to create two mutable borrows active
|
||
for the same scope to illustrate that <code>RefCell<T></code> prevents us from doing this
|
||
at runtime.</p>
|
||
<figure class="listing" id="listing-15-23">
|
||
<span class="file-name">Filename: src/lib.rs</span>
|
||
<pre><code class="language-rust ignore panics"><span class="boring">pub trait Messenger {
|
||
</span><span class="boring"> fn send(&self, msg: &str);
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">pub struct LimitTracker<'a, T: Messenger> {
|
||
</span><span class="boring"> messenger: &'a T,
|
||
</span><span class="boring"> value: usize,
|
||
</span><span class="boring"> max: usize,
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">impl<'a, T> LimitTracker<'a, T>
|
||
</span><span class="boring">where
|
||
</span><span class="boring"> T: Messenger,
|
||
</span><span class="boring">{
|
||
</span><span class="boring"> pub fn new(messenger: &'a T, max: usize) -> LimitTracker<'a, T> {
|
||
</span><span class="boring"> LimitTracker {
|
||
</span><span class="boring"> messenger,
|
||
</span><span class="boring"> value: 0,
|
||
</span><span class="boring"> max,
|
||
</span><span class="boring"> }
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> pub fn set_value(&mut self, value: usize) {
|
||
</span><span class="boring"> self.value = value;
|
||
</span><span class="boring">
|
||
</span><span class="boring"> let percentage_of_max = self.value as f64 / self.max as f64;
|
||
</span><span class="boring">
|
||
</span><span class="boring"> if percentage_of_max >= 1.0 {
|
||
</span><span class="boring"> self.messenger.send("Error: You are over your quota!");
|
||
</span><span class="boring"> } else if percentage_of_max >= 0.9 {
|
||
</span><span class="boring"> self.messenger
|
||
</span><span class="boring"> .send("Urgent warning: You've used up over 90% of your quota!");
|
||
</span><span class="boring"> } else if percentage_of_max >= 0.75 {
|
||
</span><span class="boring"> self.messenger
|
||
</span><span class="boring"> .send("Warning: You've used up over 75% of your quota!");
|
||
</span><span class="boring"> }
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">}
|
||
</span><span class="boring">
|
||
</span><span class="boring">#[cfg(test)]
|
||
</span><span class="boring">mod tests {
|
||
</span><span class="boring"> use super::*;
|
||
</span><span class="boring"> use std::cell::RefCell;
|
||
</span><span class="boring">
|
||
</span><span class="boring"> struct MockMessenger {
|
||
</span><span class="boring"> sent_messages: RefCell<Vec<String>>,
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span><span class="boring"> impl MockMessenger {
|
||
</span><span class="boring"> fn new() -> MockMessenger {
|
||
</span><span class="boring"> MockMessenger {
|
||
</span><span class="boring"> sent_messages: RefCell::new(vec![]),
|
||
</span><span class="boring"> }
|
||
</span><span class="boring"> }
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">
|
||
</span> impl Messenger for MockMessenger {
|
||
fn send(&self, message: &str) {
|
||
let mut one_borrow = self.sent_messages.borrow_mut();
|
||
let mut two_borrow = self.sent_messages.borrow_mut();
|
||
|
||
one_borrow.push(String::from(message));
|
||
two_borrow.push(String::from(message));
|
||
}
|
||
}
|
||
<span class="boring">
|
||
</span><span class="boring"> #[test]
|
||
</span><span class="boring"> fn it_sends_an_over_75_percent_warning_message() {
|
||
</span><span class="boring"> let mock_messenger = MockMessenger::new();
|
||
</span><span class="boring"> let mut limit_tracker = LimitTracker::new(&mock_messenger, 100);
|
||
</span><span class="boring">
|
||
</span><span class="boring"> limit_tracker.set_value(80);
|
||
</span><span class="boring">
|
||
</span><span class="boring"> assert_eq!(mock_messenger.sent_messages.borrow().len(), 1);
|
||
</span><span class="boring"> }
|
||
</span><span class="boring">}</span></code></pre>
|
||
<figcaption><a href="#listing-15-23">Listing 15-23</a>: Creating two mutable references in the same scope to see that <code>RefCell<T></code> will panic</figcaption>
|
||
</figure>
|
||
<p>We create a variable <code>one_borrow</code> for the <code>RefMut<T></code> smart pointer returned
|
||
from <code>borrow_mut</code>. Then, we create another mutable borrow in the same way in
|
||
the variable <code>two_borrow</code>. This makes two mutable references in the same scope,
|
||
which isn’t allowed. When we run the tests for our library, the code in Listing
|
||
15-23 will compile without any errors, but the test will fail:</p>
|
||
<pre><code class="language-console">$ cargo test
|
||
Compiling limit-tracker v0.1.0 (file:///projects/limit-tracker)
|
||
Finished `test` profile [unoptimized + debuginfo] target(s) in 0.91s
|
||
Running unittests src/lib.rs (target/debug/deps/limit_tracker-e599811fa246dbde)
|
||
|
||
running 1 test
|
||
test tests::it_sends_an_over_75_percent_warning_message ... FAILED
|
||
|
||
failures:
|
||
|
||
---- tests::it_sends_an_over_75_percent_warning_message stdout ----
|
||
|
||
thread 'tests::it_sends_an_over_75_percent_warning_message' panicked at src/lib.rs:60:53:
|
||
RefCell already borrowed
|
||
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
|
||
|
||
|
||
failures:
|
||
tests::it_sends_an_over_75_percent_warning_message
|
||
|
||
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
|
||
|
||
error: test failed, to rerun pass `--lib`
|
||
</code></pre>
|
||
<p>Notice that the code panicked with the message <code>already borrowed: BorrowMutError</code>. This is how <code>RefCell<T></code> handles violations of the borrowing
|
||
rules at runtime.</p>
|
||
<p>Choosing to catch borrowing errors at runtime rather than compile time, as
|
||
we’ve done here, means you’d potentially be finding mistakes in your code later
|
||
in the development process: possibly not until your code was deployed to
|
||
production. Also, your code would incur a small runtime performance penalty as
|
||
a result of keeping track of the borrows at runtime rather than compile time.
|
||
However, using <code>RefCell<T></code> makes it possible to write a mock object that can
|
||
modify itself to keep track of the messages it has seen while you’re using it
|
||
in a context where only immutable values are allowed. You can use <code>RefCell<T></code>
|
||
despite its trade-offs to get more functionality than regular references
|
||
provide.</p>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="having-multiple-owners-of-mutable-data-by-combining-rc-t-and-ref-cell-t"></a>
|
||
<a id="allowing-multiple-owners-of-mutable-data-with-rct-and-refcellt"></a></p>
|
||
<h3 id="allowing-multiple-owners-of-mutable-data"><a class="header" href="#allowing-multiple-owners-of-mutable-data">Allowing Multiple Owners of Mutable Data</a></h3>
|
||
<p>A common way to use <code>RefCell<T></code> is in combination with <code>Rc<T></code>. Recall that
|
||
<code>Rc<T></code> lets you have multiple owners of some data, but it only gives immutable
|
||
access to that data. If you have an <code>Rc<T></code> that holds a <code>RefCell<T></code>, you can
|
||
get a value that can have multiple owners <em>and</em> that you can mutate!</p>
|
||
<p>For example, recall the cons list example in Listing 15-18 where we used
|
||
<code>Rc<T></code> to allow multiple lists to share ownership of another list. Because
|
||
<code>Rc<T></code> holds only immutable values, we can’t change any of the values in the
|
||
list once we’ve created them. Let’s add in <code>RefCell<T></code> for its ability to
|
||
change the values in the lists. Listing 15-24 shows that by using a
|
||
<code>RefCell<T></code> in the <code>Cons</code> definition, we can modify the value stored in all
|
||
the lists.</p>
|
||
<figure class="listing" id="listing-15-24">
|
||
<span class="file-name">Filename: src/main.rs</span>
|
||
<pre class="playground"><code class="language-rust edition2024">#[derive(Debug)]
|
||
enum List {
|
||
Cons(Rc<RefCell<i32>>, Rc<List>),
|
||
Nil,
|
||
}
|
||
|
||
use crate::List::{Cons, Nil};
|
||
use std::cell::RefCell;
|
||
use std::rc::Rc;
|
||
|
||
fn main() {
|
||
let value = Rc::new(RefCell::new(5));
|
||
|
||
let a = Rc::new(Cons(Rc::clone(&value), Rc::new(Nil)));
|
||
|
||
let b = Cons(Rc::new(RefCell::new(3)), Rc::clone(&a));
|
||
let c = Cons(Rc::new(RefCell::new(4)), Rc::clone(&a));
|
||
|
||
*value.borrow_mut() += 10;
|
||
|
||
println!("a after = {a:?}");
|
||
println!("b after = {b:?}");
|
||
println!("c after = {c:?}");
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-15-24">Listing 15-24</a>: Using <code>Rc<RefCell<i32>></code> to create a <code>List</code> that we can mutate</figcaption>
|
||
</figure>
|
||
<p>We create a value that is an instance of <code>Rc<RefCell<i32>></code> and store it in a
|
||
variable named <code>value</code> so that we can access it directly later. Then, we create
|
||
a <code>List</code> in <code>a</code> with a <code>Cons</code> variant that holds <code>value</code>. We need to clone
|
||
<code>value</code> so that both <code>a</code> and <code>value</code> have ownership of the inner <code>5</code> value
|
||
rather than transferring ownership from <code>value</code> to <code>a</code> or having <code>a</code> borrow
|
||
from <code>value</code>.</p>
|
||
<p>We wrap the list <code>a</code> in an <code>Rc<T></code> so that when we create lists <code>b</code> and <code>c</code>,
|
||
they can both refer to <code>a</code>, which is what we did in Listing 15-18.</p>
|
||
<p>After we’ve created the lists in <code>a</code>, <code>b</code>, and <code>c</code>, we want to add 10 to the
|
||
value in <code>value</code>. We do this by calling <code>borrow_mut</code> on <code>value</code>, which uses the
|
||
automatic dereferencing feature we discussed in <a href="../ch05/ch05-03-method-syntax.html#wheres-the---operator">“Where’s the <code>-></code>
|
||
Operator?”</a><!-- ignore --> in Chapter 5 to dereference
|
||
the <code>Rc<T></code> to the inner <code>RefCell<T></code> value. The <code>borrow_mut</code> method returns a
|
||
<code>RefMut<T></code> smart pointer, and we use the dereference operator on it and change
|
||
the inner value.</p>
|
||
<p>When we print <code>a</code>, <code>b</code>, and <code>c</code>, we can see that they all have the modified
|
||
value of <code>15</code> rather than <code>5</code>:</p>
|
||
<pre><code class="language-console">$ cargo run
|
||
Compiling cons-list v0.1.0 (file:///projects/cons-list)
|
||
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.63s
|
||
Running `target/debug/cons-list`
|
||
a after = Cons(RefCell { value: 15 }, Nil)
|
||
b after = Cons(RefCell { value: 3 }, Cons(RefCell { value: 15 }, Nil))
|
||
c after = Cons(RefCell { value: 4 }, Cons(RefCell { value: 15 }, Nil))
|
||
</code></pre>
|
||
<p>This technique is pretty neat! By using <code>RefCell<T></code>, we have an outwardly
|
||
immutable <code>List</code> value. But we can use the methods on <code>RefCell<T></code> that provide
|
||
access to its interior mutability so that we can modify our data when we need
|
||
to. The runtime checks of the borrowing rules protect us from data races, and
|
||
it’s sometimes worth trading a bit of speed for this flexibility in our data
|
||
structures. Note that <code>RefCell<T></code> does not work for multithreaded code!
|
||
<code>Mutex<T></code> is the thread-safe version of <code>RefCell<T></code>, and we’ll discuss
|
||
<code>Mutex<T></code> in Chapter 16.</p>
|
||
</body>
|
||
</html>
|