Skip to content

Commit edc92b1

Browse files
authored
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.
1 parent 692d216 commit edc92b1

File tree

1 file changed

+9
-8
lines changed

1 file changed

+9
-8
lines changed

src/types/closure.md

Lines changed: 9 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -95,12 +95,12 @@ reference, as in the following example:
9595
```rust
9696
let mut b = false;
9797
let x = &mut b;
98-
{
99-
let mut c = || { *x = true; };
100-
// The following line is an error:
101-
// let y = &x;
102-
c();
103-
}
98+
99+
let mut c = || { *x = true; };
100+
// The following line is an error:
101+
// let y = &x;
102+
c();
103+
104104
let z = &x;
105105
```
106106

@@ -110,8 +110,9 @@ because a `& &mut` reference might not be unique, so it cannot safely be used to
110110
modify a value. So a unique immutable borrow is used: it borrows `x` immutably,
111111
but like a mutable borrow, it must be unique. In the above example, uncommenting
112112
the declaration of `y` will produce an error because it would violate the
113-
uniqueness of the closure's borrow of `x`; the declaration of z is valid because
114-
the closure's lifetime has expired at the end of the block, releasing the borrow.
113+
uniqueness of the closure's borrow of `x`; the declaration of `z` is valid because
114+
the closure's lifetime has expired, i.e. there are no `c` calls after `z`,
115+
releasing the borrow.
115116

116117
## Call traits and coercions
117118

0 commit comments

Comments
 (0)