Unwrap lines

The line wrapping was a bit inconsistent.  Let's just unwrap all the
lines on this page.

Author: traviscross

src/rust-2024/never-type-fallback.md

@@ -4,12 +4,11 @@
 
 ## Summary
 
-- Never type (`!`) to any type coercions fallback to never type (`!`)
+- Never type (`!`) to any type coercions fallback to never type (`!`).
 
 ## Details
 
-When the compiler sees a value of type ! in a [coercion site],
-it implicitly inserts a coercion to allow the type checker to infer any type:
+When the compiler sees a value of type ! in a [coercion site], it implicitly inserts a coercion to allow the type checker to infer any type:
 
 ```rust,ignore (has placeholders)
 // this
@@ -33,8 +32,7 @@ This can lead to compilation errors if the type cannot be inferred:
 { absurd(panic!()) }; // error: can't infer the type of `absurd`
 ```
 
-To prevent such errors, the compiler remembers where it inserted absurd calls,
-and if it can’t infer the type, it uses the fallback type instead:
+To prevent such errors, the compiler remembers where it inserted absurd calls, and if it can’t infer the type, it uses the fallback type instead:
 
 ```rust,ignore (has placeholders, uses code from previous example)
 type Fallback = /* An arbitrarily selected type! */;
@@ -43,29 +41,21 @@ type Fallback = /* An arbitrarily selected type! */;
 
 This is what is known as “never type fallback”.
 
-Historically, the fallback type was `()`, causing confusing behavior where `!` spontaneously coerced to `()`,
-even when it would not infer `()` without the fallback.
+Historically, the fallback type was `()`, causing confusing behavior where `!` spontaneously coerced to `()`, even when it would not infer `()` without the fallback.
 
-In the 2024 edition (and possibly in all editions on a later date) the fallback is now `!`.
-This makes it work more intuitively, now when you pass `!` and there is no reason to coerce it to
-something else, it is kept as `!`.
+In the 2024 edition (and possibly in all editions on a later date) the fallback is now `!`.  This makes it work more intuitively, now when you pass `!` and there is no reason to coerce it to something else, it is kept as `!`.
 
-In some cases your code might depend on the fallback being `()`, so this can cause compilation
-errors or changes in behavior.
+In some cases your code might depend on the fallback being `()`, so this can cause compilation errors or changes in behavior.
 
 [coercion site]: https://doc.rust-lang.org/reference/type-coercions.html#coercion-sites
 
 ## Migration
 
-There is no automatic fix, but there is automatic detection of code which will be broken by the
-edition change. While still on a previous edition you should see warnings if your code will be
-broken.
+There is no automatic fix, but there is automatic detection of code which will be broken by the edition change.  While still on a previous edition you should see warnings if your code will be broken.
 
-In either case the fix is to specify the type explicitly, so the fallback is not used.
-The complication is that it might not be trivial to see which type needs to be specified.
+In either case the fix is to specify the type explicitly, so the fallback is not used.  The complication is that it might not be trivial to see which type needs to be specified.
 
-One of the most common patterns which are broken by this change is using `f()?;` where `f` is
-generic over the ok-part of the return type:
+One of the most common patterns which are broken by this change is using `f()?;` where `f` is generic over the ok-part of the return type:
 
 ```rust,ignore (can't compile outside of a result-returning function)
 fn f<T: Default>() -> Result<T, ()> {
@@ -75,8 +65,7 @@ fn f<T: Default>() -> Result<T, ()> {
 f()?;
 ```
 
-You might think that in this example type `T` can't be inferred, however due to the current
-desugaring of `?` operator it used to be inferred to `()`, but it will be inferred to `!` now.
+You might think that in this example type `T` can't be inferred, however due to the current desugaring of `?` operator it used to be inferred to `()`, but it will be inferred to `!` now.
 
 To fix the issue you need to specify the `T` type explicitly:
 
@@ -99,16 +88,13 @@ fn run<R: Unit>(f: impl FnOnce() -> R) {
 run(|| panic!());
 ```
 
-Previously `!` from the `panic!` coerced to `()` which implements `Unit`.
-However now the `!` is kept as `!` so this code fails because `!` does not implement `Unit`.
-To fix this you can specify return type of the closure:
+Previously `!` from the `panic!` coerced to `()` which implements `Unit`.  However now the `!` is kept as `!` so this code fails because `!` does not implement `Unit`.  To fix this you can specify return type of the closure:
 
 ```rust,ignore (uses function from the previous example)
 run(|| -> () { panic!() });
 ```
 
-A similar case to the `f()?` can be seen when using a `!`-typed expression in a branch and a
-function with unconstrained return in the other:
+A similar case to the `f()?` can be seen when using a `!`-typed expression in a branch and a function with unconstrained return in the other:
 
 ```rust,edition2015
 if true {
@@ -118,8 +104,7 @@ if true {
 };
 ```
 
-Previously `()` was inferred as the return type of `Default::default()` because `!` from `return` got spuriously coerced to `()`.
-Now, `!` will be inferred instead causing this code to not compile, because `!` does not implement `Default`.
+Previously `()` was inferred as the return type of `Default::default()` because `!` from `return` got spuriously coerced to `()`.  Now, `!` will be inferred instead causing this code to not compile, because `!` does not implement `Default`.
 
 Again, this can be fixed by specifying the type explicitly: