Skip to content

Commit 9123bb0

Browse files
committed
fix borrow-splitting
1 parent b93438f commit 9123bb0

File tree

3 files changed

+9
-10
lines changed

3 files changed

+9
-10
lines changed

src/doc/tarpl/SUMMARY.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -17,7 +17,7 @@
1717
* [Subtyping and Variance](subtyping.md)
1818
* [Drop Check](dropck.md)
1919
* [PhantomData](phantom-data.md)
20-
* [Splitting Lifetimes](lifetime-splitting.md)
20+
* [Splitting Borrows](borrow-splitting.md)
2121
* [Type Conversions](conversions.md)
2222
* [Coercions](coercions.md)
2323
* [The Dot Operator](dot-operator.md)

src/doc/tarpl/lifetime-splitting.md renamed to src/doc/tarpl/borrow-splitting.md

Lines changed: 3 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
% Splitting Lifetimes
1+
% Splitting Borrows
22

33
The mutual exclusion property of mutable references can be very limiting when
44
working with a composite structure. The borrow checker understands some basic
@@ -67,9 +67,8 @@ fn split_at_mut(&mut self, mid: usize) -> (&mut [T], &mut [T]) {
6767
}
6868
```
6969

70-
This is pretty plainly dangerous. We use transmute to duplicate the slice with
71-
an *unbounded* lifetime, so that it can be treated as disjoint from the other
72-
until we unify them when we return.
70+
This is actually a bit subtle. So as to avoid ever making two `&mut`'s to the
71+
same value, we explicitly construct brand-new slices through raw pointers.
7372

7473
However more subtle is how iterators that yield mutable references work.
7574
The iterator trait is defined as follows:

src/doc/tarpl/unchecked-uninit.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -15,11 +15,11 @@ initialization.
1515

1616
Unfortunately, this opens us up to all kinds of problems. Assignment has a
1717
different meaning to Rust based on whether it believes that a variable is
18-
initialized or not. If it's uninitialized, then Rust will semantically just
19-
memcopy the bits over the uninitialized ones, and do nothing else. However if Rust
20-
believes a value to be initialized, it will try to `Drop` the old value!
21-
Since we've tricked Rust into believing that the value is initialized, we
22-
can no longer safely use normal assignment.
18+
initialized or not. If it's believed uninitialized, then Rust will semantically
19+
just memcopy the bits over the uninitialized ones, and do nothing else. However
20+
if Rust believes a value to be initialized, it will try to `Drop` the old value!
21+
Since we've tricked Rust into believing that the value is initialized, we can no
22+
longer safely use normal assignment.
2323

2424
This is also a problem if you're working with a raw system allocator, which
2525
returns a pointer to uninitialized memory.

0 commit comments

Comments
 (0)