From edc92b1bef6b4df80260161c30cb3312dac36b38 Mon Sep 17 00:00:00 2001 From: Stefanos Grammenos Date: Wed, 6 Dec 2023 13:56:37 +0200 Subject: [PATCH 1/3] Lifetime and scope clarification in `Closure types` reference. As I understood so far, lifetime is affecting the borrowing rules enforcement, scope on the other hand, has to do with memory deallocation. Most of the time, these two concepts are not overlapped. The only case I'm aware they do, is that of the temporary variables in `let` statements. --- src/types/closure.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/src/types/closure.md b/src/types/closure.md index eecdb038f..7059f2d4a 100644 --- a/src/types/closure.md +++ b/src/types/closure.md @@ -95,12 +95,12 @@ reference, as in the following example: ```rust let mut b = false; let x = &mut b; -{ - let mut c = || { *x = true; }; - // The following line is an error: - // let y = &x; - c(); -} + +let mut c = || { *x = true; }; +// The following line is an error: +// let y = &x; +c(); + let z = &x; ``` @@ -110,8 +110,9 @@ because a `& &mut` reference might not be unique, so it cannot safely be used to modify a value. So a unique immutable borrow is used: it borrows `x` immutably, but like a mutable borrow, it must be unique. In the above example, uncommenting the declaration of `y` will produce an error because it would violate the -uniqueness of the closure's borrow of `x`; the declaration of z is valid because -the closure's lifetime has expired at the end of the block, releasing the borrow. +uniqueness of the closure's borrow of `x`; the declaration of `z` is valid because +the closure's lifetime has expired, i.e. there are no `c` calls after `z`, +releasing the borrow. ## Call traits and coercions From c83ceb4f71114810587fad3067139c8bdf47ce60 Mon Sep 17 00:00:00 2001 From: Stefanos Grammenos Date: Wed, 6 Dec 2023 14:52:36 +0200 Subject: [PATCH 2/3] Style error --- src/types/closure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/types/closure.md b/src/types/closure.md index 7059f2d4a..3f0b81481 100644 --- a/src/types/closure.md +++ b/src/types/closure.md @@ -111,7 +111,7 @@ modify a value. So a unique immutable borrow is used: it borrows `x` immutably, but like a mutable borrow, it must be unique. In the above example, uncommenting the declaration of `y` will produce an error because it would violate the uniqueness of the closure's borrow of `x`; the declaration of `z` is valid because -the closure's lifetime has expired, i.e. there are no `c` calls after `z`, +the closure's lifetime has expired, i.e. there are no `c` calls after `z`, releasing the borrow. ## Call traits and coercions From 117c5b564689ec48169a88e93cd3ed05a61deeef Mon Sep 17 00:00:00 2001 From: Stefanos Grammenos Date: Thu, 12 Dec 2024 02:24:46 +0200 Subject: [PATCH 3/3] Adhere to master branch's style to avoid unnecessary diff noise. --- src/types/closure.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/types/closure.md b/src/types/closure.md index 8e026e1a9..7a42df1a8 100644 --- a/src/types/closure.md +++ b/src/types/closure.md @@ -461,7 +461,8 @@ let z = &x; ``` In this case, borrowing `x` mutably is not possible, because `x` is not `mut`. -But at the same time, borrowing `x` immutably would make the assignment illegal, because a `& &mut` reference might not be unique, so it cannot safely be used to modify a value. +But at the same time, borrowing `x` immutably would make the assignment illegal, +because a `& &mut` reference might not be unique, so it cannot safely be used to modify a value. So a unique immutable borrow is used: it borrows `x` immutably, but like a mutable borrow, it must be unique. In the above example, uncommenting the declaration of `y` will produce an error because it would violate the uniqueness of the closure's borrow of `x`; the declaration of `z` is valid because the closure's lifetime has expired, i.e. there are no `c` calls after `z`, releasing the borrow.