---

yaml
---
r: 20542
b: refs/heads/snap-stage3
c: 019a41b
h: refs/heads/master
v: v3

Author: lkuper

[refs]

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

branches/snap-stage3/doc/tutorial.md

@@ -1197,15 +1197,14 @@ Rust has three competing goals that inform its view of memory:
 
 ## How performance considerations influence the memory model
 
-Many languages that offer the kinds of memory safety guarantees that
-Rust does have a single allocation strategy: objects live on the heap,
-live for as long as they are needed, and are periodically
-garbage-collected. This approach is straightforward both in concept
-and in implementation, but has significant costs. Languages that take
-this approach tend to aggressively pursue ways to ameliorate
-allocation costs (think the Java Virtual Machine). Rust supports this
-strategy with _shared boxes_: memory allocated on the heap that may be
-referred to (shared) by multiple variables.
+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
+aggressively pursue ways to ameliorate allocation costs (think the
+Java Virtual Machine). Rust supports this strategy with _shared
+boxes_: memory allocated on the heap that may be referred to (shared)
+by multiple variables.
 
 By comparison, languages like C++ offer very precise control over
 where objects are allocated. In particular, it is common to put them