diff options
Diffstat (limited to 'src')
| -rw-r--r-- | src/doc/tarpl/SUMMARY.md | 2 | ||||
| -rw-r--r-- | src/doc/tarpl/borrow-splitting.md (renamed from src/doc/tarpl/lifetime-splitting.md) | 7 | ||||
| -rw-r--r-- | src/doc/tarpl/unchecked-uninit.md | 10 |
3 files changed, 9 insertions, 10 deletions
diff --git a/src/doc/tarpl/SUMMARY.md b/src/doc/tarpl/SUMMARY.md index a7014d7f020..aeab8fc7276 100644 --- a/src/doc/tarpl/SUMMARY.md +++ b/src/doc/tarpl/SUMMARY.md @@ -17,7 +17,7 @@ * [Subtyping and Variance](subtyping.md) * [Drop Check](dropck.md) * [PhantomData](phantom-data.md) - * [Splitting Lifetimes](lifetime-splitting.md) + * [Splitting Borrows](borrow-splitting.md) * [Type Conversions](conversions.md) * [Coercions](coercions.md) * [The Dot Operator](dot-operator.md) diff --git a/src/doc/tarpl/lifetime-splitting.md b/src/doc/tarpl/borrow-splitting.md index e320c5c7b6b..fe5f2343dec 100644 --- a/src/doc/tarpl/lifetime-splitting.md +++ b/src/doc/tarpl/borrow-splitting.md @@ -1,4 +1,4 @@ -% Splitting Lifetimes +% Splitting Borrows The mutual exclusion property of mutable references can be very limiting when 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]) { } ``` -This is pretty plainly dangerous. We use transmute to duplicate the slice with -an *unbounded* lifetime, so that it can be treated as disjoint from the other -until we unify them when we return. +This is actually a bit subtle. So as to avoid ever making two `&mut`'s to the +same value, we explicitly construct brand-new slices through raw pointers. However more subtle is how iterators that yield mutable references work. The iterator trait is defined as follows: diff --git a/src/doc/tarpl/unchecked-uninit.md b/src/doc/tarpl/unchecked-uninit.md index d0397c37190..da9fb294a1e 100644 --- a/src/doc/tarpl/unchecked-uninit.md +++ b/src/doc/tarpl/unchecked-uninit.md @@ -15,11 +15,11 @@ initialization. Unfortunately, this opens us up to all kinds of problems. Assignment has a different meaning to Rust based on whether it believes that a variable is -initialized or not. If it's uninitialized, then Rust will semantically just -memcopy the bits over the uninitialized ones, and do nothing else. However if Rust -believes a value to be initialized, it will try to `Drop` the old value! -Since we've tricked Rust into believing that the value is initialized, we -can no longer safely use normal assignment. +initialized or not. If it's believed uninitialized, then Rust will semantically +just memcopy the bits over the uninitialized ones, and do nothing else. However +if Rust believes a value to be initialized, it will try to `Drop` the old value! +Since we've tricked Rust into believing that the value is initialized, we can no +longer safely use normal assignment. This is also a problem if you're working with a raw system allocator, which returns a pointer to uninitialized memory. |