3 Rust enforces these rules through *lifetimes*. Lifetimes are effectively
4 just names for scopes somewhere in the program. Each reference,
5 and anything that contains a reference, is tagged with a lifetime specifying
6 the scope it's valid for.
8 Within a function body, Rust generally doesn't let you explicitly name the
9 lifetimes involved. This is because it's generally not really necessary
10 to talk about lifetimes in a local context; Rust has all the information and
11 can work out everything as optimally as possible. Many anonymous scopes and
12 temporaries that you would otherwise have to write are often introduced to
13 make your code Just Work.
15 However once you cross the function boundary, you need to start talking about
16 lifetimes. Lifetimes are denoted with an apostrophe: `'a`, `'static`. To dip
17 our toes with lifetimes, we're going to pretend that we're actually allowed
18 to label scopes with lifetimes, and desugar the examples from the start of
21 Originally, our examples made use of *aggressive* sugar -- high fructose corn
22 syrup even -- around scopes and lifetimes, because writing everything out
23 explicitly is *extremely noisy*. All Rust code relies on aggressive inference
24 and elision of "obvious" things.
26 One particularly interesting piece of sugar is that each `let` statement implicitly
27 introduces a scope. For the most part, this doesn't really matter. However it
28 does matter for variables that refer to each other. As a simple example, let's
29 completely desugar this simple piece of Rust code:
37 The borrow checker always tries to minimize the extent of a lifetime, so it will
38 likely desugar to the following:
41 // NOTE: `'a: {` and `&'b x` is not valid syntax!
45 // lifetime used is 'b because that's good enough.
46 let y: &'b i32 = &'b x;
49 let z: &'c &'b i32 = &'c y;
55 Wow. That's... awful. Let's all take a moment to thank Rust for being a
56 diabetes-inducing torrent of syrupy-goodness.
58 Actually passing references to outer scopes will cause Rust to infer
74 // Must use 'b here because this reference is
75 // being passed to that scope.
76 let y: &'b i32 = &'b x;
85 # Example: references that outlive referents
87 Alright, let's look at some of those examples from before:
90 fn as_str(data: &u32) -> &str {
91 let s = format!("{}", data);
99 fn as_str<'a>(data: &'a u32) -> &'a str {
101 let s = format!("{}", data);
107 This signature of `as_str` takes a reference to a u32 with *some* lifetime, and
108 promises that it can produce a reference to a str that can live *just as long*.
109 Already we can see why this signature might be trouble. That basically implies
110 that we're going to find a str somewhere in the scope the reference
111 to the u32 originated in, or somewhere *even earlier*. That's a bit of a big
114 We then proceed to compute the string `s`, and return a reference to it. Since
115 the contract of our function says the reference must outlive `'a`, that's the
116 lifetime we infer for the reference. Unfortunately, `s` was defined in the
117 scope `'b`, so the only way this is sound is if `'b` contains `'a` -- which is
118 clearly false since `'a` must contain the function call itself. We have therefore
119 created a reference whose lifetime outlives its referent, which is *literally*
120 the first thing we said that references can't do. The compiler rightfully blows
123 To make this more clear, we can expand the example:
126 fn as_str<'a>(data: &'a u32) -> &'a str {
128 let s = format!("{}", data);
137 // An anonymous scope is introduced because the borrow does not
138 // need to last for the whole scope x is valid for. The return
139 // of as_str must find a str somewhere before this function
140 // call. Obviously not happening.
141 println!("{}", as_str::<'d>(&'d x));
149 Of course, the right way to write this function is as follows:
152 fn to_string(data: &u32) -> String {
157 We must produce an owned value inside the function to return it! The only way
158 we could have returned an `&'a str` would have been if it was in a field of the
159 `&'a u32`, which is obviously not the case.
161 (Actually we could have also just returned a string literal, which as a global
162 can be considered to reside at the bottom of the stack; though this limits
163 our implementation *just a bit*.)
169 # Example: aliasing a mutable reference
171 How about the other example:
174 let mut data = vec![1, 2, 3];
182 let mut data: Vec<i32> = vec![1, 2, 3];
184 // 'b is as big as we need this borrow to be
185 // (just need to get to `println!`)
186 let x: &'b i32 = Index::index::<'b>(&'b data, 0);
188 // Temporary scope because we don't need the
189 // &mut to last any longer.
190 Vec::push(&'c mut data, 4);
197 The problem here is is bit more subtle and interesting. We want Rust to
198 reject this program for the following reason: We have a live shared reference `x`
199 to a descendent of `data` when we try to take a mutable reference to `data`
200 to `push`. This would create an aliased mutable reference, which would
201 violate the *second* rule of references.
203 However this is *not at all* how Rust reasons that this program is bad. Rust
204 doesn't understand that `x` is a reference to a subpath of `data`. It doesn't
205 understand Vec at all. What it *does* see is that `x` has to live for `'b` to
206 be printed. The signature of `Index::index` subsequently demands that the
207 reference we take to `data` has to survive for `'b`. When we try to call `push`,
208 it then sees us try to make an `&'c mut data`. Rust knows that `'c` is contained
209 within `'b`, and rejects our program because the `&'b data` must still be live!
211 Here we see that the lifetime system is much more coarse than the reference
212 semantics we're actually interested in preserving. For the most part, *that's
213 totally ok*, because it keeps us from spending all day explaining our program
214 to the compiler. However it does mean that several programs that are totally
215 correct with respect to Rust's *true* semantics are rejected because lifetimes