Merge pull request #2392 from shepmaster/spelling

Correct typos

Author: Centril

text/2349-pin.md

@@ -36,7 +36,7 @@ Let's take that goal apart, piece by piece, from the perspective of the futures
 
 At the same time, we want to support futures (and iterators, etc.) that *can* move. While it's possible to do so by providing two distinct `Future` (or `Iterator`, etc) traits, such designs incur unacceptable ergonomic costs.
 
-The key insight of this RFC is that we can create a new library type, `Pin<'a, T>`, which encompasses *both* moveable and immobile referents. The type is paired with a new auto trait, `Unpin`, which determines the meaning of `Pin<'a, T>`:
+The key insight of this RFC is that we can create a new library type, `Pin<'a, T>`, which encompasses *both* movable and immobile referents. The type is paired with a new auto trait, `Unpin`, which determines the meaning of `Pin<'a, T>`:
 
 - If `T: Unpin` (which is the default), then `Pin<'a, T>` is entirely equivalent to `&'a mut T`.
 - If `T: !Unpin`, then `Pin<'a, T>` provides a unique reference to a `T` with lifetime `'a`, but only provides `&'a T` access safely. It also guarantees that the referent will *never* be moved. However, getting `&'a mut T` access is unsafe, because operations like `mem::replace` mean that `&mut` access is enough to move data out of the referent; you must promise not to do so.
@@ -56,7 +56,7 @@ trait Future {
 
 By default when implementing `Future` for a struct, this definition is equivalent to today's, which takes `&mut self`. But if you want to allow self-referencing in your future, you just opt out of `Unpin`, and `Pin` takes care of the rest.
 
-This RFC also provides a pinned analogiy to `Box` called `PinBox<T>`. It work alongs the same lines as the `Pin` type discussed here - if the type implements `Unpin`, it functions the same as the unpinned `Box`; if the type has opted out of `Unpin`, it guarantees that they type behind the reference will not be moved again.
+This RFC also provides a pinned analogy to `Box` called `PinBox<T>`. It works along the same lines as the `Pin` type discussed here - if the type implements `Unpin`, it functions the same as the unpinned `Box`; if the type has opted out of `Unpin`, it guarantees that they type behind the reference will not be moved again.
 
 # Reference-level explanation
 
@@ -313,7 +313,7 @@ trait Generator {
 
 This would require no extensions to the standard library, but would place the
 burden on every user who wants to call resume to guarantee (at the risk of
-memory insafety) that their types were not moved, or that they were moveable.
+memory unsafety) that their types were not moved, or that they were movable.
 This seemed like a worse trade off than adding these APIs.
 
 ## Anchor as a wrapper type and `StableDeref`
@@ -326,7 +326,7 @@ been replaced with `PinBox`.
 The primary benefit of this approach was that it was partially integrated with
 crates like owning-ref and rental, which also use a hierarchy of stability
 traits. However, because of differences in the requirements, the traits used by
-owning-ref et al ended up being a non-overlapping subset of the traits proposed
+owning-ref et al. ended up being a non-overlapping subset of the traits proposed
 by this RFC from the traits used by the Anchor type. Merging these into a
 single hierarchy provided relatively little benefit.