---

yaml
---
r: 33182
b: refs/heads/snap-stage3
c: d9317a1
h: refs/heads/master
v: v3

Author: pcwalton

[refs]

@@ -1,7 +1,7 @@
 ---
 refs/heads/master: cd6f24f9d14ac90d167386a56e7a6ac1f0318195
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
-refs/heads/snap-stage3: 6da09c3b437dad240218b91ea06c301982764152
+refs/heads/snap-stage3: d9317a174e434d4c99fc1a37fd7dc0d2f5328d37
 refs/heads/try: d324a424d8f84b1eb049b12cf34182bda91b0024
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b

branches/snap-stage3/doc/tutorial.md

@@ -988,16 +988,17 @@ illuminate several of Rust's unique features as we encounter them.
 
 Rust has three competing goals that inform its view of memory:
 
-* Memory safety: memory that is managed by and is accessible to the
-  Rust language must be guaranteed to be valid; under normal
+* Memory safety: Memory that is managed by and is accessible to the
+  Rust language must be guaranteed to be valid. Under normal
   circumstances it must be impossible for Rust to trigger a
-  segmentation fault or leak memory
-* Performance: high-performance low-level code must be able to employ
-  a number of allocation strategies; low-performance high-level code
-  must be able to employ a single, garbage-collection-based, heap
-  allocation strategy
-* Concurrency: Rust must maintain memory safety guarantees, even for
-  code running in parallel
+  segmentation fault or leak memory.
+* Performance: High-performance low-level code must be able to employ
+  a number of allocation strategies. Tracing garbage collection must be
+  optional and, if it is not desired, memory safety must not be compromised.
+  Less performance-critical, high-level code should be able to employ a single,
+  garbage-collection-based, heap allocation strategy.
+* Concurrency: Rust code must be free of in-memory data races. (Note that other
+  types of races are still possible.)
 
 ## How performance considerations influence the memory model