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)
* [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)

@ -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:

@ -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.

Loading…
Cancel
Save