Skip to content

Commit db4346e

Browse files
committed
TRPL: mutability
1 parent 1114fcd commit db4346e

File tree

1 file changed

+175
-1
lines changed

1 file changed

+175
-1
lines changed

src/doc/trpl/mutability.md

Lines changed: 175 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,177 @@
11
% Mutability
22

3-
Coming Soon
3+
Mutability, the ability to change something, works a bit differently in Rust
4+
than in other languages. The first aspect of mutability is its non-defualt
5+
status:
6+
7+
```rust,ignore
8+
let x = 5;
9+
x = 6; // error!
10+
```
11+
12+
We can introduce mutability with the `mut` keyword:
13+
14+
```rust
15+
let mut x = 5;
16+
17+
x = 6; // no problem!
18+
```
19+
20+
This is a mutable [variable binding][vb]. When a binding is mutable, it means
21+
you’re allowed to change what the binding points to. So in the above example,
22+
it’s not so much that the value at `x` is changing, but that the binding
23+
changed from one `i32` to another.
24+
25+
[vb]: variable-bindings.html
26+
27+
If you want to change what the binding points to, you’ll need a [mutable reference][mr]:
28+
29+
```rust
30+
let mut x = 5;
31+
let y = &mut x;
32+
```
33+
34+
[mr]: references-and-borrowing.html
35+
36+
`y` is an immutable binding to a mutable reference, which means that you can’t
37+
bind `y` to something else, but you can mutate the thing that’s bound to `y`. A
38+
subtle distinction.
39+
40+
Of course, if you need both:
41+
42+
```rust
43+
let mut x = 5;
44+
let mut y = &mut x;
45+
```
46+
47+
Now `y` can be bound to another value, and the value it’s bound to can be
48+
changed.
49+
50+
It’s important to note that `mut` is part of a [pattern][pattern], so you
51+
can do things like this:
52+
53+
```rust
54+
let (mut x, y) = (5, 6);
55+
56+
fn foo(mut x: i32) {
57+
# }
58+
```
59+
60+
[pattern]: patterns.html
61+
62+
# Interior vs. Exterior Mutability
63+
64+
However, when we say something is ‘immutable’ in Rust, that doesn’t mean that
65+
it’s not able to be changed. We mean something has ‘exterior mutability’. Consider,
66+
for example, [`Arc<T>`][arc]:
67+
68+
```rust
69+
use std::sync::Arc;
70+
71+
let x = Arc::new(5);
72+
let y = x.clone();
73+
```
74+
75+
[arc]: ../std/sync/struct.Arc.html
76+
77+
When we call `clone()`, the `Arc<T>` needs to update the reference count. Yet
78+
we’ve not used any `mut`s here, `x` is an immutable binding, and we didn’t take
79+
`&mut 5` or anything. So what gives?
80+
81+
To this, we have to go back to the core of Rust’s guiding philosophy, memory
82+
safety, and the mechanism by which Rust guarantees it, the
83+
[ownership][ownership] system. Mutability and immutability play a role. You
84+
may, at any given time, have N immutable borrows, or a single mutable borrow.
85+
86+
[ownership]: ownership.html
87+
88+
So, that’s the real definition of ‘immutability’: is this safe to have two
89+
pointers to? In `Arc<T>`’s case, yes: the mutation is entirely contained inside
90+
the structure itself. It’s not user facing. For this reason, it hands out `&T`
91+
with `clone()`. If it handed out `&mut T`s, though, that would be a problem.
92+
93+
Other types, like the ones in the [`std::cell`][stdcell] module, have the
94+
opposite: interior mutability. For example:
95+
96+
```rust
97+
use std::cell::RefCell;
98+
99+
let x = RefCell::new(42);
100+
101+
let y = x.borrow_mut();
102+
```
103+
104+
[stdcell]: ../std/cell/index.html
105+
106+
RefCell hands out `&mut` references to what’s inside of it with the
107+
`borrow_mut()` method. Isn’t that dangerous? What if we do:
108+
109+
```rust,ignore
110+
use std::cell::RefCell;
111+
112+
let x = RefCell::new(42);
113+
114+
let y = x.borrow_mut();
115+
let z = x.borrow_mut();
116+
# (y, z);
117+
```
118+
119+
This will in fact panic, at runtime. This is what `RefCell` does: it enforces
120+
Rust’s borrowing rules at runtime, and `panic!`s if they’re violated. This
121+
allows us to get around another aspect of Rust’s mutability rules. Let’s talk
122+
about it first.
123+
124+
## Field-level mutability
125+
126+
Mutabilty is a property of either a borrow (`&mut`) or a binding (`let mut`).
127+
This means that, for example, you cannot have a [`struct`][struct] with
128+
some fields mutable and some immutable:
129+
130+
```rust,ignore
131+
struct Point {
132+
x: i32,
133+
mut y: i32, // nope
134+
}
135+
```
136+
137+
The mutability of a struct is in its binding:
138+
139+
```rust,ignore
140+
struct Point {
141+
x: i32,
142+
y: i32,
143+
}
144+
145+
let mut a = Point { x: 5, y: 6 };
146+
147+
a.x = 10;
148+
149+
let b = Point { x: 5, y: 6};
150+
151+
b.x = 10; // error: cannot assign to immutable field `b.x`
152+
```
153+
154+
[struct]: structs.html
155+
156+
157+
However, by using `RefCell<T>`, you can emulate field-level mutability:
158+
159+
```
160+
use std::cell::RefCell;
161+
162+
struct Point {
163+
x: i32,
164+
y: RefCell<i32>,
165+
}
166+
167+
let mut point = Point { x: 5, y: RefCell::new(6) };
168+
169+
{
170+
let mut y = point.y.borrow_mut();
171+
*y += 1;
172+
}
173+
174+
println!("y: {:?}", point.y);
175+
```
176+
177+
This will print `y: RefCell { value: 7 }`. We’ve successfully updated `y`.

0 commit comments

Comments
 (0)