Replace "name resolution" with "method selection"

What this RFC had referred to as "name resolution" is actually method selection, as pointed out by compiler-errors, so let's fix this everywhere. In doing this, we remove one of the purported drawbacks of RFC 2845, as it makes less sense as stated after this fix.
rust-lang · joshtriplett · Jan 16, 2025 · May 3, 2024 · May 6, 2024 · May 28, 2024
commit dc3e2fd2e6b298cec24ec9b7b3fb78c25e246739
diff --git a/text/3624-supertrait-item-shadowing-v2.md b/text/3624-supertrait-item-shadowing-v2.md
@@ -6,7 +6,7 @@
 # Summary
 [summary]: #summary
 
-When name resolution encounters an ambiguity between two trait methods when both traits are in scope, if one trait is a subtrait of the other then select that method instead of reporting an ambiguity error.
+When method selection encounters an ambiguity between two trait methods when both traits are in scope, if one trait is a subtrait of the other then select that method instead of reporting an ambiguity error.
 
 # Motivation
 [motivation]: #motivation
@@ -40,7 +40,7 @@ Attempts to stabilize `intersperse` have failed with a large number of regressio
 # Proposed solution
 [proposed-solution]: #proposed-solution
 
-This RFC proposes to change name resolution to resolve the ambiguity in the following specific circumstances:
+This RFC proposes to change method selection to resolve the ambiguity in the following specific circumstances:
 
 - All method candidates are trait methods (inherent methods are already prioritized over trait methods).
 - One trait is transitively a subtrait of all other traits in the candidate list.
@@ -63,9 +63,9 @@ If we choose not to accept this RFC then there doesn't seem to be a reasonable p
 
 ## Only doing this for specific traits
 
-One possible alternative to a general change to the name resolution rules would be to only do so on a case-by-case basis for specific methods in standard library traits. This could be done by using a perma-unstable `#[shadowable]` attribute specifically on methods like `Iterator::intersperse`.
+One possible alternative to a general change to the method selection rules would be to only do so on a case-by-case basis for specific methods in standard library traits. This could be done by using a perma-unstable `#[shadowable]` attribute specifically on methods like `Iterator::intersperse`.
 
-There are both advantages and inconveniences to this approach. While it allows most Rust users to avoid having to think about this issue for most traits, it does make the `Iterator` trait more "magical" in that it doesn't follow the same rules as the rest of the language. Having a consistent rule for how name resolution works is easier to teach people.
+There are both advantages and inconveniences to this approach. While it allows most Rust users to avoid having to think about this issue for most traits, it does make the `Iterator` trait more "magical" in that it doesn't follow the same rules as the rest of the language. Having a consistent rule for how method selection works is easier to teach people.
 
 ## Preferring the supertrait method instead
 
@@ -118,10 +118,7 @@ Resolving in favor of `a` is a breaking change; resolving in favor of `b` is not
 
 ### RFC 2845
 
-RFC 2845 was a previous attempt to address this problem, but it has several drawbacks:
-
-- It doesn't fully address the problem since it only changes name resolution when trait methods are resolved due to generic bounds. In practice, most of the ambiguity from stabilizing `intersperse` comes from non-generic code.
-- It adds a lot of complexity because name resolution depends on the specific trait bounds that have been brought into scope.
+RFC 2845 was a previous attempt, but it did not fully address the problem since it only changes method selection when trait methods are resolved due to generic bounds. In practice, most of the ambiguity from stabilizing `intersperse` comes from non-generic code.
 
 # Unresolved questions
 [unresolved-questions]: #unresolved-questions