Merge remote-tracking branch 'origin/master' into io-project

dictionary.txt

@@ -127,6 +127,7 @@ lifecycle
 loopback
 lval
 mathematic
+Metadata
 metaprogramming
 mibbit
 Mibbit
@@ -142,6 +143,7 @@ namespaced
 namespaces
 namespacing
 newfound
+newtype
 nocapture
 nomicon
 Nomicon
@@ -212,12 +214,15 @@ submodules
 Submodules
 suboptimal
 subtree
+subtyping
+Supertraits
 That'd
 test's
 TODO
 toml
 TOML
 tradeoff
+tradeoffs
 TrafficLight
 trpl
 tuple
@@ -229,6 +234,7 @@ Unary
 Uninstalling
 uninstall
 unoptimized
+UnsafeCell
 unsized
 unsynchronized
 username

src/ch13-00-functional-features.md

@@ -23,7 +23,7 @@ Difference between adapter and consumer - another iterator or consuming?
 Talk about using Associated Types here, foreshadow to advanced type systems
 chapter about why this is a different thing than normal
 
-## ??? How does this improve `greprs`
+## ??? How does this improve the I/O project from Chapter 12
 
 Does this get woven into the above sections?
 
@@ -35,5 +35,5 @@ Most complicated chain of iterator functions that compile down to the same ASM a
 
 ### Representation: Closures are a Struct
 
-Closures don't have any further perf penalty over regular fn calls
+Closures don't have any further performance penalty over regular fn calls
 

src/ch15-00-smart-pointers.md

@@ -88,7 +88,7 @@ but you need to be able to mutate the underlying data.
 Same thing as RefCell but for types that are Copy. No borrow checking rules here
 anyway. So just reason #2 above.
 
-## Is this really safe? Yes srsly
+## Is this really safe? Yes!
 
 RefCell is still doing the checks, just at runtime
 Cell is safe bc Copy types don't need the ownership rules anyway

src/ch16-00-concurrency.md

@@ -7,7 +7,7 @@ Rust's focus on aliasability ends up solving these problems.
 
 This is a library abstraction.
 
-Shared mutable state is a problem. Both useful. Functional langs get rid of
+Shared mutable state is a problem. Both useful. Functional languages get rid of
 mutability.
 
 Ownership rules (that tame the "shared" aspect) enable fearless concurrency: the
@@ -20,7 +20,7 @@ compiler is making sure you don't shoot yourself in your foot.
 ## Rust's concurrency tradeoffs
 
 Lots of different languages tackle this problem in different ways. We are not
-going to talk about that: exercise for the reader is investigate other langs
+going to talk about that: exercise for the reader is investigate other languages
 and compare and contrast with Rust's approach.
 
 This is how Rust does it, what rust means by threads
@@ -32,7 +32,7 @@ If you have a different threaded mechanism, you need a runtime, rust is trying
 to not have a heavy runtime.
 
 These are the reasons Rust's concurrency model is this way as opposed to other
-lang's ways, which are optimizing for different things.
+language's ways, which are optimizing for different things.
 
 
 ## Let's get a thread: `thread::spawn`
@@ -72,7 +72,7 @@ Steve knows the motivating code that goes here.
 
 ### `Mutex<T>`
 
-For mutabe data.
+For mutable data.
 
 `lock` method, you get a Mutex guard. Change, then unlock, which usually happens
 automatically when the Mutex guard goes out of scope. If you do this wrong, your
@@ -82,9 +82,9 @@ Deadlocks are safe, you have to manage that yourself. Deadlock bugs usually
 happen bc you forget to unlock, but drop unlocks automatically.
 
 
-## Maybe make `greprs` concurrent?
+## Maybe make the I/O project concurrent?
 
-Might be boilerplatey without scoped threads, maybe just allude.
+Might be a lot of boilerplate without scoped threads, maybe just allude.
 
 
 

src/ch17-00-oop.md

@@ -38,7 +38,7 @@ Runtime decisions about deciding what shared code we use
 
 Give example code
 
-With traits, libraries are extendable. This is why trait objects are different
+With traits, libraries are extensible. This is why trait objects are different
 than having an enum and a match statement that has to be exhaustive at compile
 time and we have to know all the things at compile time and no one can add
 new things to the set of possible things