Nit cleanup

Author: cramertj

text/0000-match-ergonomics.md

@@ -331,8 +331,8 @@ Example using `let`:
 struct Foo(i32);
 
 // Note that these rules apply to any pattern matching
-// whether it be in a `match` or a `let`. So, for example,
-// `x` here is a ref binding:
+// whether it be in a `match` or a `let`.
+// For example, `x` here is a `ref` binding:
 let Foo(x) = &Foo(3);
 
 // Desugared:
@@ -395,7 +395,7 @@ experience more straightforward and requiring fewer manual reference gymnastics.
 # Alternatives
 [alternatives]: #alternatives
 
-- We could only infer `ref`, leaving users to manually specify the `mut` in
+1. We could only infer `ref`, leaving users to manually specify the `mut` in
 `ref mut` bindings. This has the advantage of keeping mutability explicit.
 Unfortunately, it also has some unintuitive results. `ref mut` doesn't actually
 produce mutable bindings-- it produces immutably-bound mutable references.
@@ -440,12 +440,12 @@ Forcing users to manually specify `mut` in reference bindings would
 be inconsistent with Rust's current semantics, and would result in confusing
 errors.
 
-- We could support auto-ref / deref as suggested in
+2. We could support auto-ref / deref as suggested in
 [the original match ergonomics RFC.](https://github.com/rust-lang/rfcs/pull/1944)
 This approach has troublesome interaction with
 backwards-compatibility, and it becomes more difficult for the user to reason
 about whether they've borrowed or moved a value.
-- We could allow writing `move` in patterns.
+3. We could allow writing `move` in patterns.
 Without this, `move`, unlike `ref` and `ref mut`, would always be implicit,
 leaving no way override a default binding mode of `ref` or `ref mut` and move
 the value out from behind a reference.