Rework the resolution slides + grammar checks

Author: fallible-algebra

src/SUMMARY.md

@@ -440,9 +440,9 @@
   - [Extension Traits](idiomatic/leveraging-the-type-system/extension-traits.md)
     - [Extending Foreign Types](idiomatic/leveraging-the-type-system/extension-traits/extending-foreign-types.md)
     - [Method Resolution Conflicts](idiomatic/leveraging-the-type-system/extension-traits/method-resolution-conflicts.md)
+    - [Trait Method Conflicts](idiomatic/leveraging-the-type-system/extension-traits/trait-method-conflicts.md)
     - [Extending Other Traits](idiomatic/leveraging-the-type-system/extension-traits/extending-other-traits.md)
     - [Should I Define An Extension Trait?](idiomatic/leveraging-the-type-system/extension-traits/should-i-define-an-extension-trait.md)
-    - [Trait Method Conflicts](idiomatic/leveraging-the-type-system/extension-traits/trait-method-conflicts.md)
 
 ---
 

src/idiomatic/leveraging-the-type-system/extension-traits/extending-foreign-types.md

@@ -48,8 +48,8 @@ assert!(!"grandma".is_palindrome());
   that's emitted if you try to invoke an extension method without having the
   corresponding extension trait in scope.
 
-- The example above uses an [_underscore import_][3] (`use ext::StrExt as _`) to
-  minimize the likelihood of a naming conflict with other imported traits.
+- The example above uses an [_underscore import_][3] (`use ext::StringExt as _`)
+  to minimize the likelihood of a naming conflict with other imported traits.
 
   With an underscore import, the trait is considered to be in scope and you're
   allowed to invoke its methods on types that implement the trait. Its _symbol_,

src/idiomatic/leveraging-the-type-system/extension-traits/extending-other-traits.md

@@ -32,10 +32,10 @@ assert_eq!(true.quoted(), "'true'");
 <details>
 
 - Highlight how we added new behavior to _multiple_ types at once. `.quoted()`
-  can be called on string slices, numbers and booleans since they all implement
+  can be called on string slices, numbers, and booleans since they all implement
   the `Display` trait.
 
-  This flavour of the extension trait pattern uses
+  This flavor of the extension trait pattern uses
   [_blanket implementations_][1].
 
   A blanket implementation implements a trait for all types `T` that satisfy the
@@ -45,7 +45,7 @@ assert_eq!(true.quoted(), "'true'");
 - Draw the students' attention to the implementation of `DisplayExt::quoted`: we
   can't make any assumptions about `T` other than that it implements `Display`.
   All our logic must either use methods from `Display` or functions/macros that
-  don't require other traits..
+  don't require other traits.
 
   For example, we can call `format!` with `T`, but can't call `.to_uppercase()`
   because it is not necessarily a `String`.

src/idiomatic/leveraging-the-type-system/extension-traits/method-resolution-conflicts.md

@@ -9,51 +9,70 @@ extension method?
 
 ```rust,editable
 mod ext {
-    pub trait StrExt {
-        fn trim_ascii(&self) -> &str;
+    pub trait CountOnesExt {
+        fn count_ones(&self) -> u32;
     }
 
-    impl StrExt for String {
-        fn trim_ascii(&self) -> &str {
-            self.trim_start_matches(|c: char| c.is_ascii_whitespace())
+    impl CountOnesExt for i32 {
+        fn count_ones(&self) -> u32 {
+            let value = *self;
+            (0..32).filter(|i| ((value >> i) & 1i32) == 1).count() as u32
         }
     }
 }
 fn main() {
-    pub use ext::StrExt;
-    // Which `trim_ascii` method is invoked?
-    // The one from `StrExt`? Or the inherent one from `str`?
-    assert_eq!(String::from(" dad ").trim_ascii(), "dad");
+    pub use ext::CountOnesExt;
+    // Which `count_ones` method is invoked?
+    // The one from `CountOnesExt`? Or the inherent one from `i32`?
+    assert_eq!((-1i32).count_ones(), 32);
 }
 ```
 
 <details>
 
-- The foreign type may, in a newer version, add a new inherent method with the
+- A foreign type may, in a newer version, add a new inherent method with the
   same name as our extension method.
 
   Ask: What will happen in the example above? Will there be a compiler error?
   Will one of the two methods be given higher priority? Which one?
 
-  Add a `panic!("Extension trait")` in the body of `StrExt::trim_ascii` to
-  clarify which method is being invoked.
+  Add a `panic!("Extension trait");` in the body of `CountOnesExt::count_ones`
+  to clarify which method is being invoked.
 
-- [Inherent methods have higher priority than trait methods][1], _if_ they have
-  the same name and the **same receiver**, e.g., they both expect `&self` as
-  input. The situation becomes more nuanced if they use a **different
-  receiver**, e.g., `&mut self` vs `&self`.
+- To prevent users of the Rust language from having to manually specify which
+  method to use in all cases, there is a priority ordering system for how
+  methods get "picked" first:
+  - Immutable (`&self`) first
+    - Inherent (method defined in the type's `impl` block) before Trait (method
+      added by a trait impl).
+  - Mutable (`&mut self`) Second
+    - Inherent before Trait.
 
-  Change the signature of `StrExt::trim_ascii` to
-  `fn trim_ascii(&mut self) -> &str` and modify the invocation accordingly:
+  If every method with the same name has different mutability and was either
+  defined in as an inherent method or trait method, with no overlap, this makes
+  the job easy for the compiler.
+
+  This does introduce some ambiguity for the user, who may be confused as to why
+  a method they're relying on is not producing expected behavior. Avoid name
+  conflicts instead of relying on this mechanism if you can.
+
+  Demonstrate: Change the signature and implementation of
+  `CountOnesExt::count_ones` to `fn count_ones(&mut self) -> u32` and modify the
+  invocation accordingly:
 
   ```rust
-  assert_eq!((&mut " dad ").trim_ascii(), "dad");
+  assert_eq!((&mut -1i32).count_ones(), 32);
   ```
 
-  Now `StrExt::trim_ascii` is invoked, rather than the inherent method, since
+  `CountOnesExt::count_ones` is invoked, rather than the inherent method, since
   `&mut self` has a higher priority than `&self`, the one used by the inherent
   method.
 
+  If an immutable inherent method and a mutable trait method exist for the same
+  type, we can specify which one to use at the call site by using
+  `(&<value>).count_ones()` to get the immutable (higher priority) method or
+  `(&mut <value>).count_ones()`
+
   Point the students to the Rust reference for more information on
   [method resolution][2].
 

src/idiomatic/leveraging-the-type-system/extension-traits/should-i-define-an-extension-trait.md

@@ -47,7 +47,7 @@ The main advantage of extension traits is **ease of discovery**.
   several related functions for a foreign type (e.g., `is_palindrome`,
   `word_count`, `to_kebab_case`), grouping them in a single `StrExt` trait is
   often cleaner than having multiple free functions for a user to import.
-- **Tradeoffs:** Despite these advantages, a bespoke extension trait might be
+- **Trade-offs:** Despite these advantages, a bespoke extension trait might be
   overkill for a single, simple function. Both approaches require an additional
   import, and the familiar method syntax may not justify the boilerplate of a
   full trait definition.