Skip to content

Commit 44428ea

Browse files
Two lifetime clarification (#350)
1 parent 946038b commit 44428ea

File tree

1 file changed

+8
-7
lines changed

1 file changed

+8
-7
lines changed

src/lifetimes.md

Lines changed: 8 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -80,8 +80,8 @@ z = y;
8080
'b: {
8181
let z: &'b i32;
8282
'c: {
83-
// Must use 'b here because this reference is
84-
// being passed to that scope.
83+
// Must use 'b here because the reference to x is
84+
// being passed to the scope 'b.
8585
let y: &'b i32 = &'b x;
8686
z = y;
8787
}
@@ -208,11 +208,12 @@ violate the *second* rule of references.
208208

209209
However this is *not at all* how Rust reasons that this program is bad. Rust
210210
doesn't understand that `x` is a reference to a subpath of `data`. It doesn't
211-
understand `Vec` at all. What it *does* see is that `x` has to live for `'b` to
212-
be printed. The signature of `Index::index` subsequently demands that the
213-
reference we take to `data` has to survive for `'b`. When we try to call `push`,
214-
it then sees us try to make an `&'c mut data`. Rust knows that `'c` is contained
215-
within `'b`, and rejects our program because the `&'b data` must still be alive!
211+
understand `Vec` at all. What it *does* see is that `x` has to live for `'b` in
212+
order to be printed. The signature of `Index::index` subsequently demands that
213+
the reference we take to `data` has to survive for `'b`. When we try to call
214+
`push`, it then sees us try to make an `&'c mut data`. Rust knows that `'c` is
215+
contained within `'b`, and rejects our program because the `&'b data` must still
216+
be alive!
216217

217218
Here we see that the lifetime system is much more coarse than the reference
218219
semantics we're actually interested in preserving. For the most part, *that's

0 commit comments

Comments
 (0)