minor wording changes.

Author: lattner

proposals/0004-remove-pre-post-inc-decrement.md

@@ -42,33 +42,33 @@ popular languages which have kept the majority of C operators but dropped these
 ## Disadvantages of These Operators
 
 1. These operators increase the burden to learn Swift as a first programming
-language (or in other cases where you don't already know these operators from a
-different language).
+language - or any other case where you don't already know these operators from a
+different language.
 
-2. Their expressive advantage is minimal, e.g. `x++` is not much shorter
-than `x += 1`.  The later is also more clear to a reader.
+2. Their expressive advantage is minimal - `x++` is not much shorter
+than `x += 1`.
 
 3. Swift already deviates from C in that the `=`, `+=` and other assignment-like
-operations returns Void (for a number of reasons).  These operators are
+operations returns `Void` (for a number of reasons).  These operators are
 inconsistent with that model.
 
 4. Swift has powerful features that eliminate many of the common reasons you'd
 use `++i` in a C-style for loop in other languages, so these are relatively
-infrequently used in well-written Swift code.  These include features like
+infrequently used in well-written Swift code.  These features include
 the `for-in` loop, ranges, `enumerate`, `map`, etc.
 
 5. Code that actually uses the result value of these operators is often
 confusing and subtle to a reader/maintainer of code.  They encourage "overly
 tricky" code which may be cute, but difficult to understand.
 
-6. While Swift has well defined order of evaluation, any code that dependend on
+6. While Swift has well defined order of evaluation, any code that depended on
 it (like `foo(++a, a++)`) would be undesirable even if it was well-defined.
 
 7. These operators are applicable to relatively few types: integer and floating
 point scalars, and iterator-like concepts. They do not apply to complex numbers,
 matrices, etc.  
 
-8. Having to support these could add complexity to the forthcoming Swift 3
+8. Having to support these could add complexity to the potential 
 revised numerics model.
 
 Finally, these fail the metric of "if we didn't already have these, would we add
@@ -84,18 +84,18 @@ common cases), and remove them completely in Swift 3.
 
 ## Alternatives considered
 
-Two alternatives: we could keep them.  More interesting to consider, we could
+Simplest alternative: we could keep them. More interesting to consider, we could
 change these operators to return Void.  This solves some of the problems above,
 but introduces a new question: once the result is gone, the difference between
 the prefix and postfix form also vanishes.  Given that, we would have to pick 
-between unfortunate choices:
+between these unfortunate choices:
 
 1) Keep both `x++` and `++x` in the language, even though they do the same
 thing.
 
 2) Drop one of `x++` or `++x`.  C++ programmers generally prefer the prefix
 forms, but everyone else generally prefers the postfix forms.  Dropping either
-is deviating from C.
+one would be a significant deviation from C.
 
 Despite considering these options carefully, they still don't justify the
 complexity that the operators add to Swift.