Two lifetime clarification (#350)

pull/364/head
Arthur Milchior 3 years ago committed by GitHub
parent 946038b2f9
commit 44428ea589
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -80,8 +80,8 @@ z = y;
'b: { 'b: {
let z: &'b i32; let z: &'b i32;
'c: { 'c: {
// Must use 'b here because this reference is // Must use 'b here because the reference to x is
// being passed to that scope. // being passed to the scope 'b.
let y: &'b i32 = &'b x; let y: &'b i32 = &'b x;
z = y; z = y;
} }
@ -208,11 +208,12 @@ violate the *second* rule of references.
However this is *not at all* how Rust reasons that this program is bad. Rust However this is *not at all* how Rust reasons that this program is bad. Rust
doesn't understand that `x` is a reference to a subpath of `data`. It doesn't doesn't understand that `x` is a reference to a subpath of `data`. It doesn't
understand `Vec` at all. What it *does* see is that `x` has to live for `'b` to understand `Vec` at all. What it *does* see is that `x` has to live for `'b` in
be printed. The signature of `Index::index` subsequently demands that the order to be printed. The signature of `Index::index` subsequently demands that
reference we take to `data` has to survive for `'b`. When we try to call `push`, the reference we take to `data` has to survive for `'b`. When we try to call
it then sees us try to make an `&'c mut data`. Rust knows that `'c` is contained `push`, it then sees us try to make an `&'c mut data`. Rust knows that `'c` is
within `'b`, and rejects our program because the `&'b data` must still be alive! contained within `'b`, and rejects our program because the `&'b data` must still
be alive!
Here we see that the lifetime system is much more coarse than the reference Here we see that the lifetime system is much more coarse than the reference
semantics we're actually interested in preserving. For the most part, *that's semantics we're actually interested in preserving. For the most part, *that's

Loading…
Cancel
Save