<!DOCTYPE HTML>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>`RefCell<T>` and the Interior Mutability Pattern - The Rust Programming Language</title>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<meta name="description" content="">
<meta name="viewport" content="width=device-width, initial-scale=1">
<base href="">
<link rel="stylesheet" href="book.css">
<link href='https://fonts.googleapis.com/css?family=Open+Sans:300italic,400italic,600italic,700italic,800italic,400,300,600,700,800' rel='stylesheet' type='text/css'>
<link rel="shortcut icon" href="favicon.png">
<!-- Font Awesome -->
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css">
<link rel="stylesheet" href="highlight.css">
<link rel="stylesheet" href="tomorrow-night.css">
<style>
.page-wrapper.has-warning > .nav-chapters {
/* add height for warning content & margin */
top: 120px;
}
p.warning {
background-color: rgb(242, 222, 222);
border-bottom-color: rgb(238, 211, 215);
border-bottom-left-radius: 4px;
border-bottom-right-radius: 4px;
border-bottom-style: solid;
border-bottom-width: 0.666667px;
border-image-outset: 0 0 0 0;
border-image-repeat: stretch stretch;
border-image-slice: 100% 100% 100% 100%;
border-image-source: none;
border-image-width: 1 1 1 1;
border-left-color: rgb(238, 211, 215);
border-left-style: solid;
border-left-width: 0.666667px;
border-right-color: rgb(238, 211, 215);
border-right-style: solid;
border-right-width: 0.666667px;
border-top-color: rgb(238, 211, 215);
border-top-left-radius: 4px;
border-top-right-radius: 4px;
border-top-style: solid;
border-top-width: 0.666667px;
color: rgb(185, 74, 72);
margin-bottom: 0px;
margin-left: 0px;
margin-right: 0px;
margin-top: 30px;
padding-bottom: 8px;
padding-left: 14px;
padding-right: 35px;
padding-top: 8px;
}
p.warning strong {
color: rgb(185, 74, 72)
}
p.warning a {
color: rgb(0, 136, 204)
}
</style>
<!-- MathJax -->
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
<!-- Fetch JQuery from CDN but have a local fallback -->
<script src="https://code.jquery.com/jquery-2.1.4.min.js"></script>
<script>
if (typeof jQuery == 'undefined') {
document.write(unescape("%3Cscript src='jquery.js'%3E%3C/script%3E"));
}
</script>
</head>
<body class="light">
<!-- Set the theme before any content is loaded, prevents flash -->
<script type="text/javascript">
var theme = localStorage.getItem('theme');
if (theme == null) { theme = 'light'; }
$('body').removeClass().addClass(theme);
</script>
<!-- Hide / unhide sidebar before it is displayed -->
<script type="text/javascript">
var sidebar = localStorage.getItem('sidebar');
if (sidebar === "hidden") { $("html").addClass("sidebar-hidden") }
else if (sidebar === "visible") { $("html").addClass("sidebar-visible") }
</script>
<div id="sidebar" class="sidebar">
<ul class="chapter"><li><a href="ch01-00-introduction.html"><strong>1.</strong> Introduction</a></li><li><ul class="section"><li><a href="ch01-01-installation.html"><strong>1.1.</strong> Installation</a></li><li><a href="ch01-02-hello-world.html"><strong>1.2.</strong> Hello, World!</a></li></ul></li><li><a href="ch02-00-guessing-game-tutorial.html"><strong>2.</strong> Guessing Game Tutorial</a></li><li><a href="ch03-00-common-programming-concepts.html"><strong>3.</strong> Common Programming Concepts</a></li><li><ul class="section"><li><a href="ch03-01-variables-and-mutability.html"><strong>3.1.</strong> Variables and Mutability</a></li><li><a href="ch03-02-data-types.html"><strong>3.2.</strong> Data Types</a></li><li><a href="ch03-03-how-functions-work.html"><strong>3.3.</strong> How Functions Work</a></li><li><a href="ch03-04-comments.html"><strong>3.4.</strong> Comments</a></li><li><a href="ch03-05-control-flow.html"><strong>3.5.</strong> Control Flow</a></li></ul></li><li><a href="ch04-00-understanding-ownership.html"><strong>4.</strong> Understanding Ownership</a></li><li><ul class="section"><li><a href="ch04-01-what-is-ownership.html"><strong>4.1.</strong> What is Ownership?</a></li><li><a href="ch04-02-references-and-borrowing.html"><strong>4.2.</strong> References & Borrowing</a></li><li><a href="ch04-03-slices.html"><strong>4.3.</strong> Slices</a></li></ul></li><li><a href="ch05-00-structs.html"><strong>5.</strong> Using Structs to Structure Related Data</a></li><li><ul class="section"><li><a href="ch05-01-defining-structs.html"><strong>5.1.</strong> Defining and Instantiating Structs</a></li><li><a href="ch05-02-example-structs.html"><strong>5.2.</strong> An Example Program Using Structs</a></li><li><a href="ch05-03-method-syntax.html"><strong>5.3.</strong> Method Syntax</a></li></ul></li><li><a href="ch06-00-enums.html"><strong>6.</strong> Enums and Pattern Matching</a></li><li><ul class="section"><li><a href="ch06-01-defining-an-enum.html"><strong>6.1.</strong> Defining an Enum</a></li><li><a href="ch06-02-match.html"><strong>6.2.</strong> The <code>match</code> Control Flow Operator</a></li><li><a href="ch06-03-if-let.html"><strong>6.3.</strong> Concise Control Flow with <code>if let</code></a></li></ul></li><li><a href="ch07-00-modules.html"><strong>7.</strong> Modules</a></li><li><ul class="section"><li><a href="ch07-01-mod-and-the-filesystem.html"><strong>7.1.</strong> <code>mod</code> and the Filesystem</a></li><li><a href="ch07-02-controlling-visibility-with-pub.html"><strong>7.2.</strong> Controlling Visibility with <code>pub</code></a></li><li><a href="ch07-03-importing-names-with-use.html"><strong>7.3.</strong> Importing Names with <code>use</code></a></li></ul></li><li><a href="ch08-00-common-collections.html"><strong>8.</strong> Common Collections</a></li><li><ul class="section"><li><a href="ch08-01-vectors.html"><strong>8.1.</strong> Vectors</a></li><li><a href="ch08-02-strings.html"><strong>8.2.</strong> Strings</a></li><li><a href="ch08-03-hash-maps.html"><strong>8.3.</strong> Hash Maps</a></li></ul></li><li><a href="ch09-00-error-handling.html"><strong>9.</strong> Error Handling</a></li><li><ul class="section"><li><a href="ch09-01-unrecoverable-errors-with-panic.html"><strong>9.1.</strong> Unrecoverable Errors with <code>panic!</code></a></li><li><a href="ch09-02-recoverable-errors-with-result.html"><strong>9.2.</strong> Recoverable Errors with <code>Result</code></a></li><li><a href="ch09-03-to-panic-or-not-to-panic.html"><strong>9.3.</strong> To <code>panic!</code> or Not To <code>panic!</code></a></li></ul></li><li><a href="ch10-00-generics.html"><strong>10.</strong> Generic Types, Traits, and Lifetimes</a></li><li><ul class="section"><li><a href="ch10-01-syntax.html"><strong>10.1.</strong> Generic Data Types</a></li><li><a href="ch10-02-traits.html"><strong>10.2.</strong> Traits: Defining Shared Behavior</a></li><li><a href="ch10-03-lifetime-syntax.html"><strong>10.3.</strong> Validating References with Lifetimes</a></li></ul></li><li><a href="ch11-00-testing.html"><strong>11.</strong> Testing</a></li><li><ul class="section"><li><a href="ch11-01-writing-tests.html"><strong>11.1.</strong> Writing tests</a></li><li><a href="ch11-02-running-tests.html"><strong>11.2.</strong> Running tests</a></li><li><a href="ch11-03-test-organization.html"><strong>11.3.</strong> Test Organization</a></li></ul></li><li><a href="ch12-00-an-io-project.html"><strong>12.</strong> An I/O Project</a></li><li><ul class="section"><li><a href="ch12-01-accepting-command-line-arguments.html"><strong>12.1.</strong> Accepting Command Line Arguments</a></li><li><a href="ch12-02-reading-a-file.html"><strong>12.2.</strong> Reading a File</a></li><li><a href="ch12-03-improving-error-handling-and-modularity.html"><strong>12.3.</strong> Improving Error Handling and Modularity</a></li><li><a href="ch12-04-testing-the-librarys-functionality.html"><strong>12.4.</strong> Testing the Library's Functionality</a></li><li><a href="ch12-05-working-with-environment-variables.html"><strong>12.5.</strong> Working with Environment Variables</a></li><li><a href="ch12-06-writing-to-stderr-instead-of-stdout.html"><strong>12.6.</strong> Writing to <code>stderr</code> instead of <code>stdout</code></a></li></ul></li><li><a href="ch13-00-functional-features.html"><strong>13.</strong> Functional Language Features in Rust</a></li><li><ul class="section"><li><a href="ch13-01-closures.html"><strong>13.1.</strong> Closures</a></li><li><a href="ch13-02-iterators.html"><strong>13.2.</strong> Iterators</a></li><li><a href="ch13-03-improving-our-io-project.html"><strong>13.3.</strong> Improving our I/O Project</a></li><li><a href="ch13-04-performance.html"><strong>13.4.</strong> Performance</a></li></ul></li><li><a href="ch14-00-more-about-cargo.html"><strong>14.</strong> More about Cargo and Crates.io</a></li><li><ul class="section"><li><a href="ch14-01-release-profiles.html"><strong>14.1.</strong> Release Profiles</a></li><li><a href="ch14-02-publishing-to-crates-io.html"><strong>14.2.</strong> Publishing a Crate to Crates.io</a></li><li><a href="ch14-03-cargo-workspaces.html"><strong>14.3.</strong> Cargo Workspaces</a></li><li><a href="ch14-04-installing-binaries.html"><strong>14.4.</strong> Installing Binaries from Crates.io with <code>cargo install</code></a></li><li><a href="ch14-05-extending-cargo.html"><strong>14.5.</strong> Extending Cargo with Custom Commands</a></li></ul></li><li><a href="ch15-00-smart-pointers.html"><strong>15.</strong> Smart Pointers</a></li><li><ul class="section"><li><a href="ch15-01-box.html"><strong>15.1.</strong> <code>Box<T></code> Points to Data on the Heap and Has a Known Size</a></li><li><a href="ch15-02-deref.html"><strong>15.2.</strong> The <code>Deref</code> Trait Allows Access to the Data Through a Reference</a></li><li><a href="ch15-03-drop.html"><strong>15.3.</strong> The <code>Drop</code> Trait Runs Code on Cleanup</a></li><li><a href="ch15-04-rc.html"><strong>15.4.</strong> <code>Rc<T></code>, the Reference Counted Smart Pointer</a></li><li><a href="ch15-05-interior-mutability.html" class="active"><strong>15.5.</strong> <code>RefCell<T></code> and the Interior Mutability Pattern</a></li><li><a href="ch15-06-reference-cycles.html"><strong>15.6.</strong> Creating Reference Cycles and Leaking Memory is Safe</a></li></ul></li><li><a href="ch16-00-concurrency.html"><strong>16.</strong> Fearless Concurrency</a></li><li><ul class="section"><li><a href="ch16-01-threads.html"><strong>16.1.</strong> Threads</a></li><li><a href="ch16-02-message-passing.html"><strong>16.2.</strong> Message Passing</a></li><li><a href="ch16-03-shared-state.html"><strong>16.3.</strong> Shared State</a></li><li><a href="ch16-04-extensible-concurrency-sync-and-send.html"><strong>16.4.</strong> Extensible Concurrency: <code>Sync</code> and <code>Send</code></a></li></ul></li><li><a href="ch17-00-oop.html"><strong>17.</strong> Is Rust an Object-Oriented Programming Language?</a></li><li><ul class="section"><li><a href="ch17-01-what-is-oo.html"><strong>17.1.</strong> What Does Object-Oriented Mean?</a></li><li><a href="ch17-02-trait-objects.html"><strong>17.2.</strong> Trait Objects for Using Values of Different Types</a></li><li><a href="ch17-03-oo-design-patterns.html"><strong>17.3.</strong> Object-Oriented Design Pattern Implementations</a></li></ul></li><li><a href="ch18-00-patterns.html"><strong>18.</strong> Patterns Match the Structure of Values</a></li><li><ul class="section"><li><a href="ch18-01-all-the-places-for-patterns.html"><strong>18.1.</strong> All the Places Patterns May be Used</a></li><li><a href="ch18-02-refutability.html"><strong>18.2.</strong> Refutability: Whether a Pattern Might Fail to Match</a></li><li><a href="ch18-03-pattern-syntax.html"><strong>18.3.</strong> All the Pattern Syntax</a></li></ul></li><li><a href="ch19-00-advanced-features.html"><strong>19.</strong> Advanced Features</a></li><li><ul class="section"><li><a href="ch19-01-unsafe-rust.html"><strong>19.1.</strong> Unsafe Rust</a></li><li><a href="ch19-02-advanced-lifetimes.html"><strong>19.2.</strong> Advanced Lifetimes</a></li><li><a href="ch19-03-advanced-traits.html"><strong>19.3.</strong> Advanced Traits</a></li><li><a href="ch19-04-advanced-types.html"><strong>19.4.</strong> Advanced Types</a></li><li><a href="ch19-05-advanced-functions-and-closures.html"><strong>19.5.</strong> Advanced Functions & Closures</a></li></ul></li><li><a href="ch20-00-final-project-a-web-server.html"><strong>20.</strong> Final Project: Building a Multithreaded Web Server</a></li><li><ul class="section"><li><a href="ch20-01-single-threaded.html"><strong>20.1.</strong> A Single Threaded Web Server</a></li><li><a href="ch20-02-slow-requests.html"><strong>20.2.</strong> How Slow Requests Affect Throughput</a></li><li><a href="ch20-03-designing-the-interface.html"><strong>20.3.</strong> Designing the Thread Pool Interface</a></li><li><a href="ch20-04-storing-threads.html"><strong>20.4.</strong> Creating the Thread Pool and Storing Threads</a></li><li><a href="ch20-05-sending-requests-via-channels.html"><strong>20.5.</strong> Sending Requests to Threads Via Channels</a></li><li><a href="ch20-06-graceful-shutdown-and-cleanup.html"><strong>20.6.</strong> Graceful Shutdown and Cleanup</a></li></ul></li><li><a href="appendix-00.html"><strong>21.</strong> Appendix</a></li><li><ul class="section"><li><a href="appendix-01-keywords.html"><strong>21.1.</strong> A - Keywords</a></li><li><a href="appendix-02-operators.html"><strong>21.2.</strong> B - Operators</a></li><li><strong>21.3.</strong> C - Derivable Traits</li><li><strong>21.4.</strong> D - Nightly Rust</li><li><strong>21.5.</strong> E - Macros</li><li><strong>21.6.</strong> F - Translations</li><li><a href="appendix-07-newest-features.html"><strong>21.7.</strong> G - Newest Features</a></li></ul></li></ul>
</div>
<div id="page-wrapper" class="page-wrapper has-warning">
<div class="page">
<header><p class="warning">You are reading a <strong>draft</strong> of the next edition of TRPL. For more, go <a href="../index.html">here</a>.</p></header>
<div id="menu-bar" class="menu-bar">
<div class="left-buttons">
<i id="sidebar-toggle" class="fa fa-bars"></i>
<i id="theme-toggle" class="fa fa-paint-brush"></i>
</div>
<h1 class="menu-title">The Rust Programming Language</h1>
<div class="right-buttons">
<i id="print-button" class="fa fa-print" title="Print this book"></i>
</div>
</div>
<div id="content" class="content">
<a class="header" href="ch15-05-interior-mutability.html#refcellt-and-the-interior-mutability-pattern" id="refcellt-and-the-interior-mutability-pattern"><h2><code>RefCell<T></code> and the Interior Mutability Pattern</h2></a>
<p><em>Interior mutability</em> is a design pattern in Rust for allowing you to mutate
data even though there are immutable references to that data, which would
normally be disallowed by the borrowing rules. The interior mutability pattern
involves using <code>unsafe</code> code inside a data structure to bend Rust's usual rules
around mutation and borrowing. We haven't yet covered unsafe code; we will in
Chapter 19. The interior mutability pattern is used when you can ensure that
the borrowing rules will be followed at runtime, even though the compiler can't
ensure 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 by looking at the <code>RefCell<T></code> type that follows the
interior mutability pattern.</p>
<a class="header" href="ch15-05-interior-mutability.html#refcellt-has-interior-mutability" id="refcellt-has-interior-mutability"><h3><code>RefCell<T></code> has Interior Mutability</h3></a>
<p>Unlike <code>Rc<T></code>, the <code>RefCell<T></code> type represents single ownership over the data
that it holds. So, what makes <code>RefCell<T></code> different than a type like <code>Box<T></code>?
Let's recall the borrowing rules we learned in Chapter 4:</p>
<ol>
<li>At any given time, you can have <em>either</em> but not both of:</li>
</ol>
<ul>
<li>One mutable reference.</li>
<li>Any number of immutable references.</li>
</ul>
<ol start="2">
<li>References must always be valid.</li>
</ol>
<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, you'll get a <code>panic!</code>.</p>
<p>Static analysis, like the Rust compiler performs, is inherently conservative.
There are properties of code that are impossible to detect by analyzing the
code: the most famous is the Halting Problem, which is out of scope of this
book but an interesting topic to research if you're interested.</p>
<p>Because some analysis is impossible, the Rust compiler does not try to even
guess if it can't be sure, so it's conservative and sometimes rejects correct
programs that would not actually violate Rust's guarantees. Put another way, if
Rust accepts an incorrect program, people would not be able to trust in the
guarantees Rust makes. If Rust rejects a correct program, the programmer will
be inconvenienced, but nothing catastrophic can occur. <code>RefCell<T></code> is useful
when you know that the borrowing rules are respected, but the compiler can't
understand that that's true.</p>
<p>Similarly to <code>Rc<T></code>, <code>RefCell<T></code> is only for use in single-threaded
scenarios. We'll talk about how to get the functionality of <code>RefCell<T></code> in a
multithreaded program in the next chapter on concurrency. For now, all you
need to know is that if you try to use <code>RefCell<T></code> in a multithreaded
context, you'll get a compile time error.</p>
<p>With references, we use the <code>&</code> and <code>&mut</code> syntax to create references and
mutable references, respectively. But 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 <code>RefCell<T></code> has.
<code>borrow</code> returns the smart pointer type <code>Ref</code>, and <code>borrow_mut</code> returns the
smart pointer type <code>RefMut</code>. These two types implement <code>Deref</code> so that we can
treat them as if they're regular references. <code>Ref</code> and <code>RefMut</code> track the
borrows dynamically, and their implementation of <code>Drop</code> releases the borrow
dynamically.</p>
<p>Listing 15-14 shows what it looks like to use <code>RefCell<T></code> with functions that
borrow their parameters immutably and mutably. Note that the <code>data</code> variable is
declared as immutable with <code>let data</code> rather than <code>let mut data</code>, yet
<code>a_fn_that_mutably_borrows</code> is allowed to borrow the data mutably and make
changes to the data!</p>
<p><span class="filename">Filename: src/main.rs</span></p>
<pre><pre class="playpen"><code class="language-rust">use std::cell::RefCell;
fn a_fn_that_immutably_borrows(a: &i32) {
println!("a is {}", a);
}
fn a_fn_that_mutably_borrows(b: &mut i32) {
*b += 1;
}
fn demo(r: &RefCell<i32>) {
a_fn_that_immutably_borrows(&r.borrow());
a_fn_that_mutably_borrows(&mut r.borrow_mut());
a_fn_that_immutably_borrows(&r.borrow());
}
fn main() {
let data = RefCell::new(5);
demo(&data);
}
</code></pre></pre>
<p><span class="caption">Listing 15-14: Using <code>RefCell<T></code>, <code>borrow</code>, and
<code>borrow_mut</code></span></p>
<p>This example prints:</p>
<pre><code class="language-text">a is 5
a is 6
</code></pre>
<p>In <code>main</code>, we've created a new <code>RefCell<T></code> containing the value 5, and stored
in the variable <code>data</code>, declared without the <code>mut</code> keyword. We then call the
<code>demo</code> function with an immutable reference to <code>data</code>: as far as <code>main</code> is
concerned, <code>data</code> is immutable!</p>
<p>In the <code>demo</code> function, we get an immutable reference to the value inside the
<code>RefCell<T></code> by calling the <code>borrow</code> method, and we call
<code>a_fn_that_immutably_borrows</code> with that immutable reference. More
interestingly, we can get a <em>mutable</em> reference to the value inside the
<code>RefCell<T></code> with the <code>borrow_mut</code> method, and the function
<code>a_fn_that_mutably_borrows</code> is allowed to change the value. We can see that the
next time we call <code>a_fn_that_immutably_borrows</code> that prints out the value, it's
6 instead of 5.</p>
<a class="header" href="ch15-05-interior-mutability.html#borrowing-rules-are-checked-at-runtime-on-refcellt" id="borrowing-rules-are-checked-at-runtime-on-refcellt"><h3>Borrowing Rules are Checked at Runtime on <code>RefCell<T></code></h3></a>
<p>Recall from Chapter 4 that because of the borrowing rules, this code using
regular references that tries to create two mutable borrows in the same scope
won't compile:</p>
<pre><code class="language-rust ignore">let mut s = String::from("hello");
let r1 = &mut s;
let r2 = &mut s;
</code></pre>
<p>We'll get this compiler error:</p>
<pre><code class="language-text">error[E0499]: cannot borrow `s` as mutable more than once at a time
-->
|
5 | let r1 = &mut s;
| - first mutable borrow occurs here
6 | let r2 = &mut s;
| ^ second mutable borrow occurs here
7 | }
| - first borrow ends here
</code></pre>
<p>In contrast, using <code>RefCell<T></code> and calling <code>borrow_mut</code> twice in the same
scope <em>will</em> compile, but it'll panic at runtime instead. This code:</p>
<pre><pre class="playpen"><code class="language-rust should_panic">use std::cell::RefCell;
fn main() {
let s = RefCell::new(String::from("hello"));
let r1 = s.borrow_mut();
let r2 = s.borrow_mut();
}
</code></pre></pre>
<p>compiles but panics with the following error when we <code>cargo run</code>:</p>
<pre><code class="language-text"> Finished dev [unoptimized + debuginfo] target(s) in 0.83 secs
Running `target/debug/refcell`
thread 'main' panicked at 'already borrowed: BorrowMutError',
/stable-dist-rustc/build/src/libcore/result.rs:868
note: Run with `RUST_BACKTRACE=1` for a backtrace.
</code></pre>
<p>This runtime <code>BorrowMutError</code> is similar to the compiler error: it says we've
already borrowed <code>s</code> mutably once, so we're not allowed to borrow it again. We
aren't getting around the borrowing rules, we're just choosing to have Rust
enforce them at runtime instead of compile time. You could choose to use
<code>RefCell<T></code> everywhere all the time, but in addition to having to type
<code>RefCell</code> a lot, you'd find out about possible problems later (possibly in
production rather than during development). Also, checking the borrowing rules
while your program is running has a performance penalty.</p>
<a class="header" href="ch15-05-interior-mutability.html#multiple-owners-of-mutable-data-by-combining-rct-and-refcellt" id="multiple-owners-of-mutable-data-by-combining-rct-and-refcellt"><h3>Multiple Owners of Mutable Data by Combining <code>Rc<T></code> and <code>RefCell<T></code></h3></a>
<p>So why would we choose to make the tradeoffs that using <code>RefCell<T></code> involves?
Well, remember when we said that <code>Rc<T></code> only lets you have an immutable
reference to <code>T</code>? Given that <code>RefCell<T></code> is immutable, but has interior
mutability, we can combine <code>Rc<T></code> and <code>RefCell<T></code> to get a type that's both
reference counted and mutable. Listing 15-15 shows an example of how to do
that, again going back to our cons list from Listing 15-5. In this example,
instead of storing <code>i32</code> values in the cons list, we'll be storing
<code>Rc<RefCell<i32>></code> values. We want to store that type so that we can have an
owner of the value that's not part of the list (the multiple owners
functionality that <code>Rc<T></code> provides), and so we can mutate the inner <code>i32</code>
value (the interior mutability functionality that <code>RefCell<T></code> provides):</p>
<p><span class="filename">Filename: src/main.rs</span></p>
<pre><pre class="playpen"><code class="language-rust">#[derive(Debug)]
enum List {
Cons(Rc<RefCell<i32>>, Rc<List>),
Nil,
}
use List::{Cons, Nil};
use std::rc::Rc;
use std::cell::RefCell;
fn main() {
let value = Rc::new(RefCell::new(5));
let a = Cons(value.clone(), Rc::new(Nil));
let shared_list = Rc::new(a);
let b = Cons(Rc::new(RefCell::new(6)), shared_list.clone());
let c = Cons(Rc::new(RefCell::new(10)), shared_list.clone());
*value.borrow_mut() += 10;
println!("shared_list after = {:?}", shared_list);
println!("b after = {:?}", b);
println!("c after = {:?}", c);
}
</code></pre></pre>
<p><span class="caption">Listing 15-15: Using <code>Rc<RefCell<i32>></code> to create a
<code>List</code> that we can mutate</span></p>
<p>We're creating a value, which is an instance of <code>Rc<RefCell<i32>></code>. We're
storing it in a variable named <code>value</code> because we want to be able to access it
directly later. Then we create a <code>List</code> in <code>a</code> that has a <code>Cons</code> variant that
holds <code>value</code>, and <code>value</code> needs to be cloned since we want <code>value</code> to also
have ownership in addition to <code>a</code>. Then we wrap <code>a</code> in an <code>Rc<T></code> so that we
can create lists <code>b</code> and <code>c</code> that start differently but both refer to <code>a</code>,
similarly to what we did in Listing 15-12.</p>
<p>Once we have the lists in <code>shared_list</code>, <code>b</code>, and <code>c</code> created, then we add 10
to the 5 in <code>value</code> by dereferencing the <code>Rc<T></code> and calling <code>borrow_mut</code> on
the <code>RefCell</code>.</p>
<p>When we print out <code>shared_list</code>, <code>b</code>, and <code>c</code>, we can see that they all have
the modified value of 15:</p>
<pre><code class="language-text">shared_list after = Cons(RefCell { value: 15 }, Nil)
b after = Cons(RefCell { value: 6 }, Cons(RefCell { value: 15 }, Nil))
c after = Cons(RefCell { value: 10 }, Cons(RefCell { value: 15 }, Nil))
</code></pre>
<p>This is pretty neat! By using <code>RefCell<T></code>, we can have an outwardly immutable
<code>List</code>, but we can use the methods on <code>RefCell<T></code> that provide access to its
interior mutability to be able to modify our data when we need to. The runtime
checks of the borrowing rules that <code>RefCell<T></code> does protect us from data
races, and we've decided that we want to trade a bit of speed for the
flexibility in our data structures.</p>
<p><code>RefCell<T></code> is not the only standard library type that provides interior
mutability. <code>Cell<T></code> is similar but instead of giving references to the inner
value like <code>RefCell<T></code> does, the value is copied in and out of the <code>Cell<T></code>.
<code>Mutex<T></code> offers interior mutability that is safe to use across threads, and
we'll be discussing its use in the next chapter on concurrency. Check out the
standard library docs for more details on the differences between these types.</p>
</div>
<!-- Mobile navigation buttons -->
<a href="ch15-04-rc.html" class="mobile-nav-chapters previous">
<i class="fa fa-angle-left"></i>
</a>
<a href="ch15-06-reference-cycles.html" class="mobile-nav-chapters next">
<i class="fa fa-angle-right"></i>
</a>
</div>
<a href="ch15-04-rc.html" class="nav-chapters previous" title="You can navigate through the chapters using the arrow keys">
<i class="fa fa-angle-left"></i>
</a>
<a href="ch15-06-reference-cycles.html" class="nav-chapters next" title="You can navigate through the chapters using the arrow keys">
<i class="fa fa-angle-right"></i>
</a>
</div>
<!-- Local fallback for Font Awesome -->
<script>
if ($(".fa").css("font-family") !== "FontAwesome") {
$('<link rel="stylesheet" type="text/css" href="_FontAwesome/css/font-awesome.css">').prependTo('head');
}
</script>
<!-- Livereload script (if served using the cli tool) -->
<script src="highlight.js"></script>
<script src="book.js"></script>
</body>
</html>
distrib
>
Mageia
>
6
>
x86_64
>
media
>
core-updates
>
by-pkgid
>
878cdd00a13d17a73c6619a777ef5d74
>
files
>
290
