---

yaml
---
r: 22100
b: refs/heads/snap-stage3
c: ae1a730
h: refs/heads/master
v: v3

Author: brson

[refs]

@@ -1,7 +1,7 @@
 ---
 refs/heads/master: e430a699f2c60890d9b86069fd0c68a70ece7120
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
-refs/heads/snap-stage3: 1880d783b73387c1baac9e5cb0167d7a0f6e768c
+refs/heads/snap-stage3: ae1a73029ce422ccd52c3c659a32c19ac60d0d4e
 refs/heads/try: ffbe0e0e00374358b789b0037bcb3a577cd218be
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b

branches/snap-stage3/doc/tutorial.md

@@ -957,7 +957,7 @@ Rust has three competing goals that inform its view of memory:
 Most languages that offer strong memory safety guarantees rely upon a
 garbage-collected heap to manage all of the objects. This approach is
 straightforward both in concept and in implementation, but has
-significant costs. Languages that take this approach tend to
+significant costs. Languages that follow this path tend to
 aggressively pursue ways to ameliorate allocation costs (think the
 Java Virtual Machine). Rust supports this strategy with _managed
 boxes_: memory allocated on the heap whose lifetime is managed
@@ -982,7 +982,7 @@ tasks. Experience in other languages has proven that isolating each
 task's heap from the others is a reliable strategy and one that is
 easy for programmers to reason about. Heap isolation has the
 additional benefit that garbage collection must only be done
-per-heap. Rust never "stops the world" to garbage-collect memory.
+per-heap. Rust never "stops the world" to reclaim memory.
 
 Complete isolation of heaps between tasks implies that any data
 transferred between tasks must be copied. While this is a fine and