From 14deb7ec4c2b8ac020750f160c226c6591c1f1ac Mon Sep 17 00:00:00 2001
From: LukeMathWalker <20745048+LukeMathWalker@users.noreply.github.com>
Date: Mon, 7 Jul 2025 13:33:17 +0200
Subject: [PATCH] Formatting.

---
 src/idiomatic/leveraging-the-type-system.md        | 14 +++++++-------
 .../newtype-pattern/semantic-confusion.md          |  6 ++++--
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/src/idiomatic/leveraging-the-type-system.md b/src/idiomatic/leveraging-the-type-system.md
index a1153fdc..17448b09 100644
--- a/src/idiomatic/leveraging-the-type-system.md
+++ b/src/idiomatic/leveraging-the-type-system.md
@@ -26,15 +26,15 @@ Additional items speaker may mention:
   types. ["Domain Modeling Made Functional"][1] is a great resource on the
   topic, with examples written in F#.
 
-- Despite Rust's functional roots, functional design patterns don't translate as-is
-  to Rust. For instance, extensive use of higher-order functions and higher-kinded types can
-  result in code that is harder to read and maintain. Design patterns in Rust
-  must take into account (and leverage!) the granular control over mutability
-  that comes with its borrow checker.
+- Despite Rust's functional roots, functional design patterns don't translate
+  as-is to Rust. For instance, extensive use of higher-order functions and
+  higher-kinded types can result in code that is harder to read and maintain.
+  Design patterns in Rust must take into account (and leverage!) the granular
+  control over mutability that comes with its borrow checker.
 
 - The same caution should be applied to object-oriented design patterns. Rust
-  doesn't support inheritance, and object decomposition should take into account the
-  constraints introduced by the borrow checker.
+  doesn't support inheritance, and object decomposition should take into account
+  the constraints introduced by the borrow checker.
 
 - Mention that type-level programming can be often used to create "zero-cost
   abstractions", although the label can be misleading: the impact on compile
diff --git a/src/idiomatic/leveraging-the-type-system/newtype-pattern/semantic-confusion.md b/src/idiomatic/leveraging-the-type-system/newtype-pattern/semantic-confusion.md
index 20d59897..6cabb87d 100644
--- a/src/idiomatic/leveraging-the-type-system/newtype-pattern/semantic-confusion.md
+++ b/src/idiomatic/leveraging-the-type-system/newtype-pattern/semantic-confusion.md
@@ -4,7 +4,8 @@ minutes: 5
 
 # Semantic Confusion
 
-When a function takes multiple arguments of the same type, call sites are unclear:
+When a function takes multiple arguments of the same type, call sites are
+unclear:
 
 ```rust
 # struct LoginError;
@@ -49,7 +50,8 @@ login(password, username);
 
 - Nonetheless, note that there are legitimate scenarios where a function may
   take multiple arguments of the same type. In those scenarios, if correctness
-  is of paramount importance, consider using a struct with named fields as input:
+  is of paramount importance, consider using a struct with named fields as
+  input:
   ```rust
   pub struct LoginArguments {
       pub username: &str,