Remove typos and fix grammar

Author: shepmaster

text/1522-conservative-impl-trait.md

@@ -97,7 +97,7 @@ Here are some problems that unboxed abstract types solve or mitigate:
 
 * _Returning unboxed closures_. Closure syntax generates an anonymous type
   implementing a closure trait. Without unboxed abstract types, there is no way
-  to use this syntax while returning the resulting closure unboxed, because there
+  to use this syntax while returning the resulting closure unboxed because there
   is no way to write the name of the generated type.
 
 * _Leaky APIs_. Functions can easily leak implementation details in their return
@@ -141,7 +141,7 @@ with other extensions.
 ## Syntax
 
 Let's start with the bikeshed: The proposed syntax is `impl Trait` in return type
-position, composing like trait objects to forms like `impl Foo+Send+'a`.
+position, composing like trait objects to forms like `impl Foo + Send + 'a`.
 
 It can be explained as "a type that implements `Trait`",
 and has been used in that form in most earlier discussions and proposals.
@@ -162,7 +162,7 @@ The core semantics of the feature is described below.
 
 Note that the sections after this one go into more detail on some of the design
 decisions, and that **it is likely for many of the mentioned limitations to be
-lifted at some point in the future**. For clarity, we'll separately categories the *core
+lifted at some point in the future**. For clarity, we'll separately categorize the *core
 semantics* of the feature (aspects that would stay unchanged with future extensions)
 and the *initial limitations* (which are likely to be lifted later).
 
@@ -181,7 +181,7 @@ and the *initial limitations* (which are likely to be lifted later).
   - The type would not be known to implement any other trait, with
     the exception of OIBITS (aka "auto traits") and default traits like `Sized`.
   - The type would not be considered equal to the actual underlying type.
-  - The type would not be allowed to appear as the Self type for an `impl` block.
+  - The type would not be allowed to appear as the `Self` type for an `impl` block.
 
 - Because OIBITS like `Send` and `Sync` will leak through an abstract return
   type, there will be some additional complexity in the compiler due to some
@@ -223,7 +223,7 @@ and the *initial limitations* (which are likely to be lifted later).
   unless these are themselves part of a legal return type.
 
   - Eventually, we will want to allow the feature to be used within traits, and
-    like in argument position as well (as an ergonomic improvement over today's generics).
+    likely in argument position as well (as an ergonomic improvement over today's generics).
   - Using `impl Trait` multiple times in the same return type would be valid,
     like for example in `-> (impl Foo, impl Bar)`.
 
@@ -252,7 +252,7 @@ and the *initial limitations* (which are likely to be lifted later).
 
 ## Rationale
 
-### Why this semantics for the return type?
+### Why these semantics for the return type?
 
 There has been a lot of discussion about what the semantics of the return type
 should be, with the theoretical extremes being "full return type inference" and
@@ -410,11 +410,11 @@ so the syntax is forbidden there.
 
 ### Compatibility with conditional trait bounds
 
-On valid critique for the existing `impl Trait` proposal is that it does not
-cover more complex scenarios, where the return type would implement
+One valid critique for the existing `impl Trait` proposal is that it does not
+cover more complex scenarios where the return type would implement
 one or more traits depending on whether a type parameter does so with another.
 
-For example, a iterator adapter might want to implement `Iterator` and
+For example, an iterator adapter might want to implement `Iterator` and
 `DoubleEndedIterator`, depending on whether the adapted one does:
 
 ```rust
@@ -426,7 +426,7 @@ impl<I: DoubleEndedIterator> DoubleEndedIterator for SkipOne<I> { ... }
 
 Using just `-> impl Iterator`, this would not be possible to reproduce.
 
-Since there has been no proposals so far that would address this in a way
+Since there have been no proposals so far that would address this in a way
 that would conflict with the fixed-trait-set case, this RFC punts on that issue as well.
 
 ### Limitation to free/inherent functions
@@ -435,10 +435,10 @@ One important usecase of abstract return types is to use them in trait methods.
 
 However, there is an issue with this, namely that in combinations with generic
 trait methods, they are effectively equivalent to higher kinded types.
-Which is an issue because Rust HKT story is not yet figured out, so
+Which is an issue because Rust's HKT story is not yet figured out, so
 any "accidental implementation" might cause unintended fallout.
 
-HKT allows you to be generic over a type constructor, aka a
+HKT allows you to be generic over a type constructor, a.k.a. a
 "thing with type parameters", and then instantiate them at some later point to
 get the actual type.
 For example, given a HK type `T` that takes one type as parameter, you could
@@ -459,7 +459,7 @@ with a `u32` or `bool`,
 just like `T<u32>` and `T<bool>` might give us `Vec<u32>` or `Box<bool>`
 in the example above.
 
-The problem does not exists with trait method return types today because
+The problem does not exist with trait method return types today because
 they are concrete:
 
 ```rust
@@ -472,7 +472,7 @@ Given the above code, there is no way for `bar` to choose a return type `X`
 that could fundamentally differ between instantiations of `Self`
 while still being instantiable with an arbitrary `U`.
 
-At most you could return a associated type, but then you'd loose the generics
+At most you could return a associated type, but then you'd lose the generics
 from `bar`
 
 ```rust
@@ -482,7 +482,7 @@ trait Foo {
 }
 ```
 
-So, in conclusion, since Rusts HKT story is not yet fleshed out,
+So, in conclusion, since Rust's HKT story is not yet fleshed out,
 and the compatibility of the current compiler with it is unknown,
 it is not yet possible to reach a concrete solution here.