Apply suggestions from code review

Co-authored-by: Ibraheem Ahmed <[email protected]>
Co-authored-by: bstrie <[email protected]>

Author: 3 people

text/0000-edition-2021.md

@@ -6,7 +6,7 @@
 # Summary
 [summary]: #summary
 
-This RFC describes the plan for the 2021 Edition. It supercedes [RFC 2052]. The proposed 2021 Edition is intentionally more limited than the 2018 Edition. Rather than representing a major marketing push, the 2021 Edition represents a chance for us to introduce changes that would otherwise be backwards incompatible. It is meant to be marketed in many ways as something closer to "just another release".
+This RFC describes the plan for the 2021 Edition. It supersedes [RFC 2052]. The proposed 2021 Edition is intentionally more limited than the 2018 Edition. Rather than representing a major marketing push, the 2021 Edition represents a chance for us to introduce changes that would otherwise be backwards incompatible. It is meant to be marketed in many ways as something closer to "just another release".
 
 Key points include:
 
@@ -64,11 +64,11 @@ Our goal is to see all Rust users adopt the new edition, just as we would genera
 
 ## Rust should feel like "one language"
 
-Editions introduce backwards incompatible changes to Rust, which in turn introduces the risk that Rust begins to feel like a language with many dialects. We want to avoid the experience that people come to a Rust project and feel unsure about what a given piece of code means or what kinds of features they can use. This is why we prefer year-based editions (e.g., Rust 2018, Rust 2021) that group together a number of changes, rather than fine-grained opt-in; year-based editions can be succintly described, and ensure that when you go to a codebase, it is relatively easy to determine what set of features is available.
+Editions introduce backwards incompatible changes to Rust, which in turn introduces the risk that Rust begins to feel like a language with many dialects. We want to avoid the experience that people come to a Rust project and feel unsure about what a given piece of code means or what kinds of features they can use. This is why we prefer year-based editions (e.g., Rust 2018, Rust 2021) that group together a number of changes, rather than fine-grained opt-in; year-based editions can be succinctly described, and ensure that when you go to a codebase, it is relatively easy to determine what set of features is available.
 
 ### Uniform behavior across editions
 
-Persuant to the goal of having Rust feel like "one language", we generally prefer uniform behavior across all editions of Rust, so long as it can be achieved without compromising other design goals. This means for example that if we add a new feature that is backwards compatible, it should be made available in all editions. Similarly, if we deprecate a pattern that we think is problematic, it should be deprecated across all editions.
+Pursuant to the goal of having Rust feel like "one language", we generally prefer uniform behavior across all editions of Rust, so long as it can be achieved without compromising other design goals. This means for example that if we add a new feature that is backwards compatible, it should be made available in all editions. Similarly, if we deprecate a pattern that we think is problematic, it should be deprecated across all editions.
 
 Having uniform behavior across editions has several benefits:
 
@@ -104,7 +104,7 @@ The default edition for new projects will be 2021.
 
 ## RFCs that propose edition changes
 
-RFCs that propose migrations should include details about how the migration between editions will work. This migration should be described in sufficient detail that the relevant teams can assess the feasibility of the migration. It will often make sense to consult the compiler team on this question specificially. 
+RFCs that propose migrations should include details about how the migration between editions will work. This migration should be described in sufficient detail that the relevant teams can assess the feasibility of the migration. It will often make sense to consult the compiler team on this question specifically.
 
 * To perform this evaluation, an RFC proposing a migration should enumerate the situations that will no longer compile with the change. 
 * For each such situation, it should describe what suggestions will be made to modify the user's code such that it works on both the old and new edition. Optionally, the description may include "idiom lints" that run only in the new edition in order to make the code more idiomatic.
@@ -173,7 +173,7 @@ The following metrics are an attempt to quantify some of the goals we have for e
 * 90% of crater-seen crates migrate without manual intervention.
     * This can be measured automatically, subject to the limitations of crater (e.g., linux only).
 * 90% of crates that were migrated to the newer edition could be migrated in less than 1 hour
-    * This includes both rustfix but also manual migraton.
+    * This includes both rustfix but also manual migration.
     * This will require a survey or other forms of self-reporting.
 
 ### Adoption
@@ -217,7 +217,7 @@ This model works well for larger, sweeping changes, such as the changes to modul
 [prior-art]: #prior-art
 
 - [RFC 2052] introduced Rust's editions.
-- Ember's notion of feature-driven editions were introduced in [Ember RFC 364](https://github.com/emberjs/rfcs/blob/master/text/0364-roadmap-2018.md).
+- Ember's notion of feature-driven editions was introduced in [Ember RFC 364](https://github.com/emberjs/rfcs/blob/master/text/0364-roadmap-2018.md).
 - As noted in [RFC 2052], C/C++ and Java compilers both have ways of specifying which version of the standard the code is expected to conform to.
 - The [XSLT programming language](https://www.w3.org/TR/xslt-30/) had explicit version information embedded in every program that was used to guide transitions. (Author's note: nikomatsakis used to work on an XSLT compiler and cannot resist citing this example. nikomatsakis also discovered that there is apparently an XSLT 3.0 now. 👀)
 
@@ -235,4 +235,4 @@ The lang team is expected to decide the final policy on warnings and idiom lints
 # Future possibilities
 [future-possibilities]: #future-possibilities
 
-None.
+None.