---

yaml
---
r: 208027
b: refs/heads/snap-stage3
c: 0476586
h: refs/heads/master
i:
  208025: 9711a0e
  208023: 5e0494a
v: v3

Author: jsyeo

[refs]

@@ -1,7 +1,7 @@
 ---
 refs/heads/master: 38a97becdf3e6a6157f6f7ec2d98ade8d8edc193
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
-refs/heads/snap-stage3: 477cf9c606803801fd9d2bba098b01e78123a27f
+refs/heads/snap-stage3: 04765866436a6d89642bdd69f3d8fb1e8012a463
 refs/heads/try: 7b4ef47b7805a402d756fb8157101f64880a522f
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/dist-snap: ba4081a5a8573875fed17545846f6f6902c8ba8d

branches/snap-stage3/src/doc/complement-lang-faq.md

@@ -109,7 +109,7 @@ This does mean that indexed access to a Unicode codepoint inside a `str` value i
 * Most "character oriented" operations on text only work under very restricted language assumptions sets such as "ASCII-range codepoints only". Outside ASCII-range, you tend to have to use a complex (non-constant-time) algorithm for determining linguistic-unit (glyph, word, paragraph) boundaries anyways. We recommend using an "honest" linguistically-aware, Unicode-approved algorithm.
 * The `char` type is UCS4. If you honestly need to do a codepoint-at-a-time algorithm, it's trivial to write a `type wstr = [char]`, and unpack a `str` into it in a single pass, then work with the `wstr`. In other words: the fact that the language is not "decoding to UCS4 by default" shouldn't stop you from decoding (or re-encoding any other way) if you need to work with that encoding.
 
-## Why are `str`s, slices, arrays etc. built-in types rather than (say) special kinds of trait/impl?
+## Why are strings, vectors etc. built-in types rather than (say) special kinds of trait/impl?
 
 In each case there is one or more operator, literal constructor, overloaded use or integration with a built-in control structure that makes us think it would be awkward to phrase the type in terms of more-general type constructors. Same as, say, with numbers! But this is partly an aesthetic call, and we'd be willing to look at a worked-out proposal for eliminating or rephrasing these special cases.
 

branches/snap-stage3/src/doc/trpl/SUMMARY.md

@@ -5,7 +5,6 @@
     * [Hello, world!](hello-world.md)
     * [Hello, Cargo!](hello-cargo.md)
 * [Learn Rust](learn-rust.md)
-    * [Guessing Game](guessing-game.md)
 * [Effective Rust](effective-rust.md)
     * [The Stack and the Heap](the-stack-and-the-heap.md)
     * [Testing](testing.md)
@@ -27,6 +26,7 @@
     * [References and Borrowing](references-and-borrowing.md)
     * [Lifetimes](lifetimes.md)
     * [Mutability](mutability.md)
+    * [Move semantics](move-semantics.md)
     * [Enums](enums.md)
     * [Match](match.md)
     * [Structs](structs.md)

branches/snap-stage3/src/doc/trpl/error-handling.md

@@ -252,7 +252,7 @@ struct Info {
 }
 
 fn write_info(info: &Info) -> io::Result<()> {
-    let mut file = File::create("my_best_friends.txt").unwrap();
+    let mut file = File::open("my_best_friends.txt").unwrap();
 
     if let Err(e) = writeln!(&mut file, "name: {}", info.name) {
         return Err(e)
@@ -282,7 +282,7 @@ struct Info {
 }
 
 fn write_info(info: &Info) -> io::Result<()> {
-    let mut file = try!(File::create("my_best_friends.txt"));
+    let mut file = try!(File::open("my_best_friends.txt"));
 
     try!(writeln!(&mut file, "name: {}", info.name));
     try!(writeln!(&mut file, "age: {}", info.age));