---

yaml
---
r: 228992
b: refs/heads/try
c: adcd30c
h: refs/heads/master
v: v3

Author: Gankra

[refs]

@@ -1,7 +1,7 @@
 ---
 refs/heads/master: aca2057ed5fb7af3f8905b2bc01f72fa001c35c8
 refs/heads/snap-stage3: 1af31d4974e33027a68126fa5a5a3c2c6491824f
-refs/heads/try: 59ff3a39ae866b862678a769f469f0bae55606e5
+refs/heads/try: adcd30c5a2aa732174b0c5deba3f4b9c9a9a44d0
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
 refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503

branches/try/safe-unsafe-meaning.md

@@ -98,7 +98,7 @@ destructors will be successfully called! Hooray!
 
 However BTreeMap is implemented using a modest spoonful of Unsafe (most collections
 are). That means that it is not necessarily *trivially true* that a bad Ord
-implementation will make BTreeMap behave safely. Unsafe most be sure not to rely
+implementation will make BTreeMap behave safely. Unsafe must be sure not to rely
 on Ord *where safety is at stake*, because Ord is provided by Safe, and memory
 safety is not Safe's responsibility to uphold. *It must be impossible for Safe
 code to violate memory safety*.