|
```
-We'll see how to convert between types [later in this course](../04_traits/08_from).
+We'll see how to convert between types [later in this course](../04_traits/09_from).
## References
We'll talk about operator overloading [later in the course](../04_traits/03_operator_overloading), after we've covered traits.
[^coercion]: There are some exceptions to this rule, mostly related to references, smart pointers and ergonomics. We'll
-cover those [later on](../04_traits/06_deref).
+cover those [later on](../04_traits/07_deref).
A mental model of "all conversions are explicit" will serve you well in the meantime.
# Panics
-Let's go back to the `speed` function you wrote for the ["Variables" section](../02_variables/README.md).
+Let's go back to the `speed` function you wrote for the ["Variables" section](02_variables).
It probably looked something like this:
```rust
for primitive types and a few other special cases.
When working with composite types, you'll have to rely on
different conversion mechanisms ([fallible](../05_ticket_v2/13_try_from)
-and [infallible](../04_traits/08_from)), which we'll explore later on.
+and [infallible](../04_traits/09_from)), which we'll explore later on.
## References
You've seen this in action in the previous exercise on visibility.
We now need to provide one or more public **constructors**—i.e. static methods or functions that can be used
from outside the module to create a new instance of the struct.
-Luckily enough we already have one: `Ticket::new`, as implemented in [a previous exercise](../02_validation/README.md).
+Luckily enough we already have one: `Ticket::new`, as implemented in [a previous exercise](02_validation).
## Accessor methods
- The exercise for this section is located in `exercises/03_ticket_v1/10_references_in_memory`
-[^fat]: [Later in the course](../04_traits/05_str_slice) we'll talk about **fat pointers**,
+[^fat]: [Later in the course](../04_traits/06_str_slice) we'll talk about **fat pointers**,
i.e. pointers with additional metadata. As the name implies, they are larger than
the pointers we discussed in this chapter, also known as **thin pointers**.
it would have been reasonable to expect `&str` to be represented as a single `usize` on
the stack, a pointer. That's not the case though. `&str` stores some **metadata** next
to the pointer: the length of the slice it points to. Going back to the example from
-[a previous section](05_str_slice.md):
+[a previous section](06_str_slice):
```rust
let mut s = String::with_capacity(5);
pub trait Error: Debug + Display {}
```
-You might recall the `:` syntax from [the `Sized` trait](../04_traits/07_sized.md)—it's used to specify **supertraits**.
+You might recall the `:` syntax from [the `Sized` trait](../04_traits/08_sized.md)—it's used to specify **supertraits**.
For `Error`, there are two supertraits: `Debug` and `Display`. If a type wants to implement `Error`, it must also
implement `Debug` and `Display`.
# `TryFrom` and `TryInto`
-In the previous chapter we looked at the [`From` and `Into` traits](../04_traits/08_from.md),
+In the previous chapter we looked at the [`From` and `Into` traits](../04_traits/09_from.md),
Rust's idiomatic interfaces for **infallible** type conversions.
But what if the conversion is not guaranteed to succeed?