From 56fd7834f6d8e888430f0531d8fcff28cb99b51c Mon Sep 17 00:00:00 2001 From: Alexis Beingessner Date: Tue, 28 Jul 2015 15:38:39 -0700 Subject: [PATCH] fix borrow-splitting --- SUMMARY.md | 2 +- lifetime-splitting.md => borrow-splitting.md | 7 +++---- unchecked-uninit.md | 10 +++++----- 3 files changed, 9 insertions(+), 10 deletions(-) rename lifetime-splitting.md => borrow-splitting.md (97%) diff --git a/SUMMARY.md b/SUMMARY.md index a7014d7..aeab8fc 100644 --- a/SUMMARY.md +++ b/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/lifetime-splitting.md b/borrow-splitting.md similarity index 97% rename from lifetime-splitting.md rename to borrow-splitting.md index e320c5c..fe5f234 100644 --- a/lifetime-splitting.md +++ b/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/unchecked-uninit.md b/unchecked-uninit.md index d0397c3..da9fb29 100644 --- a/unchecked-uninit.md +++ b/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.