fix borrow-splitting

pull/10/head
Alexis Beingessner 9 years ago committed by Manish Goregaokar
parent e00022c2ef
commit 56fd7834f6

@ -17,7 +17,7 @@
* [Subtyping and Variance](subtyping.md) * [Subtyping and Variance](subtyping.md)
* [Drop Check](dropck.md) * [Drop Check](dropck.md)
* [PhantomData](phantom-data.md) * [PhantomData](phantom-data.md)
* [Splitting Lifetimes](lifetime-splitting.md) * [Splitting Borrows](borrow-splitting.md)
* [Type Conversions](conversions.md) * [Type Conversions](conversions.md)
* [Coercions](coercions.md) * [Coercions](coercions.md)
* [The Dot Operator](dot-operator.md) * [The Dot Operator](dot-operator.md)

@ -1,4 +1,4 @@
% Splitting Lifetimes % Splitting Borrows
The mutual exclusion property of mutable references can be very limiting when The mutual exclusion property of mutable references can be very limiting when
working with a composite structure. The borrow checker understands some basic 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 This is actually a bit subtle. So as to avoid ever making two `&mut`'s to the
an *unbounded* lifetime, so that it can be treated as disjoint from the other same value, we explicitly construct brand-new slices through raw pointers.
until we unify them when we return.
However more subtle is how iterators that yield mutable references work. However more subtle is how iterators that yield mutable references work.
The iterator trait is defined as follows: The iterator trait is defined as follows:

@ -15,11 +15,11 @@ initialization.
Unfortunately, this opens us up to all kinds of problems. Assignment has a 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 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 initialized or not. If it's believed uninitialized, then Rust will semantically
memcopy the bits over the uninitialized ones, and do nothing else. However if Rust just memcopy the bits over the uninitialized ones, and do nothing else. However
believes a value to be initialized, it will try to `Drop` the old value! 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 Since we've tricked Rust into believing that the value is initialized, we can no
can no longer safely use normal assignment. longer safely use normal assignment.
This is also a problem if you're working with a raw system allocator, which This is also a problem if you're working with a raw system allocator, which
returns a pointer to uninitialized memory. returns a pointer to uninitialized memory.

Loading…
Cancel
Save