Formatter

book/src/05_ticket_v2/00_intro.md

@@ -13,4 +13,3 @@ We'll need to introduce a few more concepts along the way:
 - The `Error` trait, to mark error types
 - The `TryFrom` and `TryInto` traits, for fallible conversions
 - Rust's package system, explaining what's a library, what's a binary, how to use third-party crates
-

book/src/05_ticket_v2/01_enum.md

@@ -41,4 +41,3 @@ enum Status {
 ```
 
 `enum`, just like `struct`, defines **a new Rust type**.
-

book/src/05_ticket_v2/02_match.md

@@ -68,4 +68,3 @@ match status {
 ```
 
 The `_` pattern matches anything that wasn't matched by the previous patterns.
-

book/src/05_ticket_v2/03_variants_with_data.md

@@ -86,4 +86,3 @@ match status {
     }
 }
 ```
-

book/src/05_ticket_v2/04_if_let.md

@@ -64,4 +64,3 @@ as the code that precedes it.
 Both `if let` and `let/else` are idiomatic Rust constructs.\
 Use them as you see fit to improve the readability of your code,
 but don't overdo it: `match` is always there when you need it.
-

book/src/05_ticket_v2/05_nullability.md

@@ -72,4 +72,3 @@ assert_eq!(second.2, 8);
 ```
 
 Tuples are a convenient way of grouping values together when you can't be bothered to define a dedicated struct type.
-

book/src/05_ticket_v2/06_fallibility.md

@@ -81,4 +81,3 @@ That's the big advantage of `Result`: it makes fallibility explicit.
 
 Keep in mind, though, that panics exist. They aren't tracked by the type system, just like exceptions in other languages.
 But they're meant for **unrecoverable errors** and should be used sparingly.
-

book/src/05_ticket_v2/07_unwrap.md

@@ -38,4 +38,3 @@ When you call a function that returns a `Result`, you have two key options:
       Err(err) => eprintln!("Error: {}", err),
   }
   ```
-

book/src/05_ticket_v2/08_error_enums.md

@@ -36,4 +36,3 @@ match s.parse_u32() {
     }
 }
 ```
-

book/src/05_ticket_v2/09_error_trait.md

@@ -50,4 +50,3 @@ The difference is in their _purpose_: `Display` returns a representation that's
 while `Debug` provides a low-level representation that's more suitable to developers and service operators.\
 That's why `Debug` can be automatically implemented using the `#[derive(Debug)]` attribute, while `Display`
 **requires** a manual implementation.
-

book/src/05_ticket_v2/10_packages.md

@@ -61,4 +61,3 @@ binary crate inside. If you want to create a library crate instead, you can use
 ```bash
 cargo new my-library --lib
 ```
-

book/src/05_ticket_v2/11_dependencies.md

@@ -52,4 +52,3 @@ static_assertions = "1.1.0"
 ```
 
 We've been using a few of these throughout the book to shorten our tests.
-

book/src/05_ticket_v2/12_thiserror.md

@@ -39,4 +39,3 @@ In the case of `thiserror`, we have:
 - `#[derive(thiserror::Error)]`: this is the syntax to derive the `Error` trait for a custom error type, helped by `thiserror`.
 - `#[error("{0}")]`: this is the syntax to define a `Display` implementation for each variant of the custom error type.
   `{0}` is replaced by the zero-th field of the variant (`String`, in this case) when the error is displayed.
-

book/src/05_ticket_v2/13_try_from.md

@@ -38,4 +38,3 @@ being attempted.
 
 Just like `From` and `Into`, `TryFrom` and `TryInto` are dual traits.\
 If you implement `TryFrom` for a type, you get `TryInto` for free.
-

book/src/05_ticket_v2/14_source.md

@@ -148,4 +148,3 @@ fn read_file() -> Result<String, std::io::Error> {
 You can use the `?` operator to shorten your error handling code significantly.\
 In particular, the `?` operator will automatically convert the error type of the fallible operation into the error type
 of the function, if a conversion is possible (i.e. if there is a suitable `From` implementation)
-