From 07d6fcb294db7bd34e78ddde492aded4f7578a24 Mon Sep 17 00:00:00 2001 From: Arthur Milchior Date: Thu, 5 May 2022 07:04:10 +0200 Subject: [PATCH] Two lifetime clarification In the first change "this" and "that" is slightly ambiguous, at least for a first introduction. Actually, I'm not 100% sure I got it right, but at least, if I got it wrong, it proves my point it needed clarification The second change is simply because "x has to live (for 'b to be printed)" seemeds to mean that "'b" will be printed. I hope it makes clear that the actual parsing is "(x has to live for 'b) in order to be printed" --- src/lifetimes.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/src/lifetimes.md b/src/lifetimes.md index b35a8c6..ef86b7b 100644 --- a/src/lifetimes.md +++ b/src/lifetimes.md @@ -80,8 +80,8 @@ z = y; 'b: { let z: &'b i32; 'c: { - // Must use 'b here because this reference is - // being passed to that scope. + // Must use 'b here because the reference to x is + // being passed to the scope 'b. let y: &'b i32 = &'b x; 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 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 -be printed. The signature of `Index::index` subsequently demands that the -reference we take to `data` has to survive for `'b`. When we try to call `push`, -it then sees us try to make an `&'c mut data`. Rust knows that `'c` is contained -within `'b`, and rejects our program because the `&'b data` must still be alive! +understand `Vec` at all. What it *does* see is that `x` has to live for `'b` in +order to be printed. The signature of `Index::index` subsequently demands that +the reference we take to `data` has to survive for `'b`. When we try to call +`push`, it then sees us try to make an `&'c mut data`. Rust knows that `'c` is +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 semantics we're actually interested in preserving. For the most part, *that's