---

yaml
---
r: 236119
b: refs/heads/stable
c: 9123bb0
h: refs/heads/master
i:
  236117: 12b2a60
  236115: cfbeec6
  236111: bd12372
v: v3

Author: Gankra

[refs]

@@ -29,7 +29,7 @@ refs/heads/tmp: afae2ff723393b3ab4ccffef6ac7c6d1809e2da0
 refs/tags/1.0.0-alpha.2: 4c705f6bc559886632d3871b04f58aab093bfa2f
 refs/tags/homu-tmp: f859507de8c410b648d934d8f5ec1c52daac971d
 refs/tags/1.0.0-beta: 8cbb92b53468ee2b0c2d3eeb8567005953d40828
-refs/heads/stable: b93438f648233ccdc98d80bcba53d78f672522f9
+refs/heads/stable: 9123bb02ca3d71e16ce3e4a2ebb1fca49fcd93e2
 refs/tags/1.0.0: 55bd4f8ff2b323f317ae89e254ce87162d52a375
 refs/tags/1.1.0: bc3c16f09287e5545c1d3f76b7abd54f2eca868b
 refs/tags/1.2.0: f557861f822c34f07270347b94b5280de20a597e

branches/stable/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)

branches/stable/src/doc/tarpl/lifetime-splitting.md renamed to branches/stable/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:

branches/stable/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.