reword existing method -> pre-edition method

Author: yaahc

text/0000-edition-based-method-disambiguation.md

@@ -7,20 +7,20 @@
 [summary]: #summary
 
 This RFC proposes a way to introduce new trait methods that conflict with
-existing trait methods in downstream crates in a backwards compatible fashion.
+pre-edition[^1] trait methods in downstream crates in a backwards compatible fashion.
 We do so by annotating new methods with the edition they're introduced in. Then
 when ambigutity is detected between a new method in the standard library and an
-existing downstream method the compiler will check if the crate edition matches
+pre-edition downstream method the compiler will check if the crate edition matches
 the edition that the method was introduced in. If it does we pick the
-presumably pre-existing downstream method and output a warning that there was
+pre-edition method and output a warning that there was
 an ambigutity with a newly introduced std method and that this warning will be
 promoted to a hard error in the next edition.
 
 # Motivation
 [motivation]: #motivation
 
 Rust has had a long standing issue with breaking changes caused by introducing
-new methods that conflict with existing downstream methods. This issue is best
+new methods that conflict with pre-edition downstream methods. This issue is best
 exemplified with the recent attempt to move `Itertools::intersperse` into the
 `Iterator` trait which [broke a large number of
 crates](https://github.com/rust-lang/rust/issues/88967). Continuing as we have
@@ -34,9 +34,9 @@ introduce methods like these without causing any breakage.
 *written as though this feature is already implemented and stable*
 
 The rust standard library recently added support for adding new methods to
-traits that conflict with existing methods with the same name on other traits
-without causing breakage due to ambiguity. Since adding this feature you may
-start running into errors that look like this
+traits that conflict with pre-edition[^1] methods with the same name on other
+traits without causing breakage due to ambiguity. Since adding this feature you
+may start running into errors that look like this
 
 ```
 warning[E0034]: multiple applicable items in scope
@@ -73,7 +73,7 @@ lifecycle, where methods are experimented within 3rd party crates and then
 moved into the standard library once they've been thorougly tested. A classic
 example of this is the `Itertools` crate for experimenting with extentions to
 the `Iterator` trait. However this problem isn't restricted to extension traits
-of existing standard library traits, and can indeed become a problem whenever
+of pre-edition standard library traits, and can indeed become a problem whenever
 any two methods have the same name.
 
 You can fix issues like this by manually editing the code to select the
@@ -82,10 +82,10 @@ can use cargo fix. cargo fix will make assumptions about how the methods relate
 depending on if you're using cargo fix for an edition upgrade or not.
 
 * **Within same edition** cargo fix will assume that the new method is a drop
-  in replacement of the existing downstream one and will disambiguate by
+  in replacement of the pre-edition downstream one and will disambiguate by
   selecting the upstream method defined in `std`.
 * **As part of an edition upgrade** cargo fix will prioritize maintaining the
-  same behavior, and will disambiguate by selecting the existing method that
+  same behavior, and will disambiguate by selecting the pre-edition method that
   was being used previously.
 
 To run cargo fix within the same edition run:
@@ -104,7 +104,7 @@ cargo fix --edition
 ```
 
 In the example above this would replace the ambiguous code with
-`Itertools::intersperse(it, sep)`, maintaining the existing behavior.
+`Itertools::intersperse(it, sep)`, maintaining the pre-edition behavior.
 
 # Reference-level explanation
 [reference-level-explanation]: #reference-level-explanation
@@ -122,11 +122,11 @@ normal and emit an error for the ambiguity.
 
 This flag should be usable to resolve the following forms of breakage:
 
-* A new method on an existing trait ([e.g.
+* A new method on an pre-edition trait ([e.g.
   itertools::intersperse](https://github.com/rust-lang/rust/issues/88967))
-* A new trait implementation of an existing trait on an existing types ([e.g.
+* A new trait implementation of an pre-edition trait on an pre-edition type ([e.g.
   ErrorKind Display](https://github.com/rust-lang/rust/issues/94507))
-* A new inherent method on an existing type (no recent examples)
+* A new inherent method on an pre-edition type (no recent examples)
 
 # Drawbacks
 [drawbacks]: #drawbacks
@@ -149,7 +149,11 @@ disambiguating the trait a method call should come from.
 # Rationale and alternatives
 [rationale-and-alternatives]: #rationale-and-alternatives
 
-[This comment](https://github.com/rust-lang/rust/issues/88967#issuecomment-938024847) on the `Iterator::intersperse` issue details a few alternatives that were discussed by the libs team when we encountered that specific issue. These include both short term and long term suggestions.
+[This
+comment](https://github.com/rust-lang/rust/issues/88967#issuecomment-938024847)
+on the `Iterator::intersperse` issue details a few alternatives that were
+discussed by the libs team when we encountered that specific issue. These
+include both short term and long term suggestions.
 
 **Short Term**
 
@@ -188,15 +192,19 @@ supertrait.
 ## Interaction with autoderef
 
 We already have logic for preferring stable methods to unstable methods but it
-breaks[^1] if the auto deref for one requires one more level of indirection
+breaks[^2] if the auto deref for one requires one more level of indirection
 than the other. We should be careful to consider how autoderef behavior can
 affect edition based method disambiguation.
 
-[^1]: https://github.com/rust-lang/rust/issues/86682
 
 # Future possibilities
 [future-possibilities]: #future-possibilities
 
 As this RFC previously pointed out in the drawbacks section, introducing a new
 syntax for unambiguous method calls for a specific trait would significantly
 improve the experience of resolving these warnings.
+
+[^1]: Definition: Pre-edition methods are methods that could legally have been
+  introduced during the current edition which do not conflict with any methods
+  that existed during the initial release of the current edition.
+[^2]: https://github.com/rust-lang/rust/issues/86682