Address most of the trivial feedback, run formatter

Author: fallible-algebra

src/SUMMARY.md

@@ -440,8 +440,8 @@
   - [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)
-    - [Should I Define An Extension Trait?](idiomatic/leveraging-the-type-system/extension-traits/should-i-define-an-extension-trait.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.md

@@ -55,8 +55,10 @@ pattern** to work around this limitation.
 
   Rust has decided to avoid the issue altogether by forbidding the definition of
   new inherent methods on foreign types.
-  
-- Other languages (e.g, Kotlin, C#, Swift) allow adding methods to existing types, often called "extension methods." This leads to different trade-offs in terms of potential ambiguities and the need for global reasoning.
+
+- Other languages (e.g, Kotlin, C#, Swift) allow adding methods to existing
+  types, often called "extension methods." This leads to different trade-offs in
+  terms of potential ambiguities and the need for global reasoning.
 
 </details>
 

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

@@ -38,7 +38,8 @@ assert!(!"grandma".is_palindrome());
   Refer to the ["Extension Trait" RFC][1] as the authoritative source for naming
   conventions.
 
-- The extension trait implementation for a foreign type must be in the same crate as the trait itself, otherwise you'll be blocked by Rust's
+- The extension trait implementation for a foreign type must be in the same
+  crate as the trait itself, otherwise you'll be blocked by Rust's
   [_orphan rule_][2].
 
 - The extension trait must be in scope when its methods are invoked.

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

@@ -31,35 +31,41 @@ 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 the `Display` trait.
+- 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
+  the `Display` trait.
 
   This flavour of the extension trait pattern uses
   [_blanket implementations_][1].
 
-  A blanket implementation implements a trait for all types `T`
-  that satisfy the trait bounds specified in the `impl` block. In
-  this case, the only requirement is that `T` implements the `Display` trait.
+  A blanket implementation implements a trait for all types `T` that satisfy the
+  trait bounds specified in the `impl` block. In this case, the only requirement
+  is that `T` implements the `Display` trait.
 
 - 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..
+  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..
+
+  For example, we can call `format!` with `T`, but can't call `.to_uppercase()`
+  because it is not necessarily a `String`.
 
-  For example, we can call `format!` with `T`, but can't call `.to_uppercase()` because it is not necessarily a `String`.
-  
   We could introduce additional trait bounds on `T`, but it would restrict the
   set of types that can leverage the extension trait.
 
 - Conventionally, the extension trait is named after the trait it extends,
   followed by the `Ext` suffix. In the example above, `DisplayExt`.
 
-- There are entire crates that extend standard library traits with new functionality.
+- There are entire crates that extend standard library traits with new
+  functionality.
+
+  - `itertools` crate provides the `Itertools` trait that extends `Iterator`. It
+    adds many iterator adapters, such as `interleave` and `unique`. It provides
+    new algorithmic building blocks for iterator pipelines built with method
+    chaining.
 
-  - `itertools` crate provides the `Itertools` trait that extends `Iterator`. It adds many iterator adapters, such as `interleave` and `unique`. It provides new algorithmic building blocks for iterator pipelines built with method chaining.
-  
-  - `futures` crate provides the `FutureExt` trait, which extends the `Future` trait with new combinators and helper methods.
+  - `futures` crate provides the `FutureExt` trait, which extends the `Future`
+    trait with new combinators and helper methods.
 
 ## More To Explore
 

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

@@ -7,41 +7,41 @@ minutes: 15
 What happens when you have a name conflict between an inherent method and an
 extension method?
 
-```rust
+```rust,editable
 mod ext {
     pub trait StrExt {
         fn trim_ascii(&self) -> &str;
     }
 
-    impl StrExt for &str {
+    impl StrExt for String {
         fn trim_ascii(&self) -> &str {
             self.trim_start_matches(|c: char| c.is_ascii_whitespace())
         }
     }
 }
-
-pub use ext::StrExt;
-// Which `trim_ascii` method is invoked?
-// The one from `StrExt`? Or the inherent one from `str`?
-assert_eq!(" dad ".trim_ascii(), "dad");
+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");
+}
 ```
 
 <details>
 
 - The foreign type may, in a newer version, add a new inherent method with the
   same name as our extension method.
 
-  Survey the class: what do the students think will happen in the example above?
-  Will there be a compiler error? Will one of the two methods be given higher
-  priority? Which one?
+  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.
 
 - [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`.
+  input. The situation becomes more nuanced if they use a **different
+  receiver**, e.g., `&mut self` vs `&self`.
 
   Change the signature of `StrExt::trim_ascii` to
   `fn trim_ascii(&mut self) -> &str` and modify the invocation accordingly:

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

@@ -28,8 +28,28 @@ The main advantage of extension traits is **ease of discovery**.
 
 <details>
 
-- Extension methods can be easier to discover than free functions. Language servers (e.g., `rust-analyzer`) will suggest them if you type `.` after an instance of the foreign type.
-
-- However, a bespoke extension trait might be overkill for a single method. Both approaches require an additional import, and the familiar method syntax may not justify the boilerplate of a full trait definition.
+- Extension methods can be easier to discover than free functions. Language
+  servers (e.g., `rust-analyzer`) will suggest them if you type `.` after an
+  instance of the foreign type.
+
+- However, a bespoke extension trait might be overkill for a single method. Both
+  approaches require an additional import, and the familiar method syntax may
+  not justify the boilerplate of a full trait definition.
+
+- **Discoverability:** Extension methods are easier to discover than free
+  functions. Language servers (e.g., `rust-analyzer`) will suggest them if you
+  type `.` after an instance of the foreign type.
+- **Method Chaining:** A major ergonomic win for extension traits is method
+  chaining. This is the foundation of the `Iterator` trait, allowing for fluent
+  calls like `data.iter().filter(...).map(...)`. Achieving this with free
+  functions would be far more cumbersome (`map(filter(iter(data), ...), ...)`).
+- **API Cohesion:** Extension traits help create a cohesive API. If you have
+  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
+  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.
 
 </details>

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

@@ -45,16 +45,16 @@ assert!("dad".is_palindrome());
   the same type may define a method with a name that conflicts with your own
   extension method.
 
-  Survey the class: what do the students think will happen in the example above?
-  Will there be a compiler error? Will one of the two methods be given higher
-  priority? Which one?
+  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?
 
 - The compiler rejects the code because it cannot determine which method to
   invoke. Neither `Ext1` nor `Ext2` has a higher priority than the other.
 
   To resolve this conflict, you must specify which trait you want to use. For
   example, you can call `Ext1::is_palindrome("dad")` or
-  `Ext2::is_palindrome("dad")`. Demonstrate this syntax and that the updated code compiles.
+  `Ext2::is_palindrome("dad")`. Demonstrate this syntax and that the updated
+  code compiles.
 
   For methods with more complex signatures, you may need to use a more explicit
   [fully-qualified syntax][1].