Merge pull request #2453 from shepmaster/standard-rust-style

Correct typos and use standard Rust style for `dyn Trait` RFCs

Author: Centril

text/2113-dyn-trait-syntax.md

@@ -25,7 +25,7 @@ Because it makes traits and trait objects appear indistinguishable. Some specifi
 - `impl MyTrait {}` is valid syntax, which can easily be mistaken for adding default impls of methods or adding extension methods or some other useful operation on the trait itself. In reality, it adds inherent methods to the trait object.
 - Function types and function traits only differ in the capitalization of one letter. This leads to function pointers `&fn ...` and function trait objects `&Fn ...` differing only in one letter, making it very easy to mistake one for the other.
 
-Making one of these mistakes typically leads to an error about the trait not implemeting Sized, which is at best misleading and unhelpful. It may be possible to produce better error messages today, but the compiler can only do so much when most of this "obviously wrong" syntax is technically legal.
+Making one of these mistakes typically leads to an error about the trait not implementing Sized, which is at best misleading and unhelpful. It may be possible to produce better error messages today, but the compiler can only do so much when most of this "obviously wrong" syntax is technically legal.
 
 ### favors a feature that is not more frequently used than its alternatives
 

text/2250-finalize-impl-dyn-syntax.md

@@ -13,7 +13,7 @@ stabilization of these features.
 [motivation]: #motivation
 
 Current priority of `+` in `impl Trait1 + Trait2` / `dyn Trait1 + Trait2` brings
-inconsistency in the type grammar.  
+inconsistency in the type grammar.
 This RFC outlines possible syntactic
 alternatives and suggests one of them for stabilization.
 
@@ -28,7 +28,7 @@ contexts where they are used inside of unary operators `&(impl Trait1 + Trait2)`
 prefix, e.g. `&(Trait1 + Trait2)`.
 
 Additionally, parentheses are required in all cases where `+` in `impl` or `dyn`
-is ambiguous.  
+is ambiguous.
 For example, `Fn() -> impl A + B` can be interpreted as both
 `(Fn() -> impl A) + B` (low priority plus) or `Fn() -> (impl A + B)` (high
 priority plus), so we are refusing to disambiguate and require explicit
@@ -67,8 +67,8 @@ bring inconsistency and may break intuition.
 
 Pros:
 - The greedy parsing with high priority of `+` after `impl` / `dyn`
-has one benefit - it requires the least amout of parentheses from all the
-alternatives.  
+has one benefit - it requires the least amount of parentheses from all the
+alternatives.
 Parentheses are needed only when the greedy behaviour needs to be prevented,
 e.g. `Fn() -> &(dyn Write) + Send`, this doesn't happen often.
 
@@ -86,7 +86,7 @@ work, as if `impl` were an unary operator.
 Basically, `impl A + B` is parsed using same rules as `A + B`.
 
 If `impl A + B` is located inside a higher priority operator like `&` it has
-to be parenthesized.  
+to be parenthesized.
 If it is located at intersection of type and expressions
 grammars like `expr1 as Type + expr2`, it has to be parenthesized as well.
 
@@ -96,23 +96,21 @@ grammars like `expr1 as Type + expr2`, it has to be parenthesized as well.
 One location must be mentioned specially, the location in a function return
 type:
 ```rust
-fn f() -> impl A + B
-{
+fn f() -> impl A + B {
     // Do things
 }
 ```
 This is probably the most common location for `impl Trait` types.
 In theory, it doesn't require parentheses in any way - it's not inside of an
-unary operator and it doesn't cross expression boundaries.  
-However, it creates a bit of percieved inconsistency with function-like traits
+unary operator and it doesn't cross expression boundaries.
+However, it creates a bit of perceived inconsistency with function-like traits
 and function pointers that do require parentheses for `impl Trait` in return
 types (`Fn() -> (impl A + B)` / `fn() -> (impl A + B)`) because they, in their
-turn, can appear inside of unary operators and casts.  
+turn, can appear inside of unary operators and casts.
 So, if avoiding this is considered more important than ergonomics, then
 we can require parentheses in function definitions as well.
 ```rust
-fn f() -> (impl A + B)
-{
+fn f() -> (impl A + B) {
     // Do things
 }
 ```
@@ -130,7 +128,7 @@ is not a valid syntax.
 ## Alternative 3: Unary operator
 
 `impl` and `dyn` can become usual unary operators in type grammar like `&` or
-`*const`.  
+`*const`.
 Their application to any other types except for (possibly parenthesized) paths
 (single `A`) or "legacy trait objects" (`A + B`) becomes an error, but this
 could be changed in the future if some other use is found.
@@ -140,8 +138,7 @@ could be changed in the future if some other use is found.
 
 Function definitions with `impl A + B` in return type have to be rewritten too.
 ```rust
-fn f() -> impl(A + B)
-{
+fn f() -> impl(A + B) {
     // Do things
 }
 ```
@@ -151,7 +148,7 @@ Pros:
 - `impl` / `dyn` are usual unary operators, `dyn (A + B)` is a valid syntax.
 
 Cons:
-- The largest amount of parentheses, parentheses are always required.  
+- The largest amount of parentheses, parentheses are always required.
 Parentheses are noise, there may be even less desire to use `dyn` in trait
 objects now, if something like `Box<Write + Send>` turns into
 `Box<dyn(Write + Send)>`.
@@ -175,15 +172,15 @@ after `impl` / `dyn`.
 
 Alternative 2 can be backward-compatibly extended to "relaxed 3" in which
 parentheses like `dyn (A + B)` are permitted, but technically unnecessary.
-Such parens may keep people expecting `dyn (A + B)` to work happy, but
+Such parenthesis may keep people expecting `dyn (A + B)` to work happy, but
 complicate parsing by introducing more ambiguities to the grammar.
 
 While unary operators like `&` "obviously" have higher priority than `+`,
-cases like `Fn() -> impl A + B` are not so obvious.  
+cases like `Fn() -> impl A + B` are not so obvious.
 The Alternative 2 considers "low priority plus" to have lower priority than `Fn`
 , so `Fn() -> impl A + B` can be treated as `(Fn() -> impl A) + B`, however
 it may be more intuitive and consistent with `fn` items to make `+` have higher
-priority than `Fn` (but still lower priority than `&`).  
+priority than `Fn` (but still lower priority than `&`).
 As an immediate solution we refuse to disambiguate this case and treat
 `Fn() -> impl A + B` as an error, so we can change the rules in the future and
 interpret `Fn() -> impl A + B` (and maybe even `Fn() -> A + B` after long
@@ -199,9 +196,9 @@ changes required to move to Alternatives 2 and 3. Alternative 2 requires fewer
 changes compared to Alternative 3.
 
 As the RFC author interprets it, the Alternative 3 turns out to be impractical
-due to common use of `Box`es and other contexts where the parens are technically
-unnecessary, but required by Alternative 3.  
-The number of parens required by Alternative 2 is limited and they seem
+due to common use of `Box`es and other contexts where the parenthesis are technically
+unnecessary, but required by Alternative 3.
+The number of parenthesis required by Alternative 2 is limited and they seem
 appropriate because they follow "normal" priorities for unary and binary
 operators.