---

yaml
---
r: 28570
b: refs/heads/try
c: 5e9d38e
h: refs/heads/master
v: v3

Author: brson

[refs]

@@ -2,7 +2,7 @@
 refs/heads/master: cd6f24f9d14ac90d167386a56e7a6ac1f0318195
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
 refs/heads/snap-stage3: cd6f24f9d14ac90d167386a56e7a6ac1f0318195
-refs/heads/try: 76c8b83efad38b05c5f4d140b8084dcb7b75fc38
+refs/heads/try: 5e9d38ede0f0eff5fec3ad8713897c080211d5ea
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b
 refs/heads/try2: d0c6ce338884ee21843f4b40bf6bf18d222ce5df

branches/try/doc/rust.md

@@ -222,7 +222,7 @@ pure
 return
 struct
 true trait type
-unchecked unsafe
+unsafe
 while
 ~~~~~~~~
 
@@ -1035,23 +1035,24 @@ pure fn nonempty_list<T>(ls: List<T>) -> bool { pure_length(ls) > 0u }
 
 *TODO:* should actually define referential transparency.
 
-The effect checking rules previously enumerated are a restricted set of
-typechecking rules meant to approximate the universe of observably
-referentially transparent Rust procedures conservatively. Sometimes, these
-rules are *too* restrictive. Rust allows programmers to violate these rules by
-writing pure functions that the compiler cannot prove to be referentially
-transparent, using an escape-hatch feature called "unchecked blocks". When
-writing code that uses unchecked blocks, programmers should always be aware
-that they have an obligation to show that the code *behaves* referentially
-transparently at all times, even if the compiler cannot *prove* automatically
-that the code is referentially transparent. In the presence of unchecked
-blocks, the compiler provides no static guarantee that the code will behave as
-expected at runtime. Rather, the programmer has an independent obligation to
-verify the semantics of the pure functions they write.
+The effect checking rules previously enumerated are a restricted set
+of typechecking rules meant to approximate the universe of observably
+referentially transparent Rust procedures conservatively. Sometimes,
+these rules are *too* restrictive. Rust allows programmers to violate
+these rules by writing pure functions that the compiler cannot prove
+to be referentially transparent, using "unsafe blocks". When writing
+code that uses unsafe blocks, programmers should always be aware that
+they have an obligation to show that the code *behaves* referentially
+transparently at all times, even if the compiler cannot *prove*
+automatically that the code is referentially transparent. In the
+presence of unsafe blocks, the compiler provides no static guarantee
+that the code will behave as expected at runtime. Rather, the
+programmer has an independent obligation to verify the semantics of
+the pure functions they write.
 
 *TODO:* last two sentences are vague.
 
-An example of a pure function that uses an unchecked block:
+An example of a pure function that uses an unsafe block:
 
 ~~~~
 # use std::list::*;
@@ -1065,7 +1066,7 @@ fn pure_foldl<T, U: Copy>(ls: List<T>, u: U, f: fn(&&T, &&U) -> U) -> U {
 
 pure fn pure_length<T>(ls: List<T>) -> uint {
     fn count<T>(_t: T, &&u: uint) -> uint { u + 1u }
-    unchecked {
+    unsafe {
         pure_foldl(ls, 0u, count)
     }
 }