Enums, short for enumerations, are well-known programming constructs that many languages feature. These special cases of types allow a number to be mapped to a name. This can be used to tie constants together under a single name and lets us declare values as variants. For example, we could have pi, as well as Euler's number, as variants of an enum, MathConstants. Rust is no different, but it can go a lot further. Instead of simply relying on naming numbers, Rust allows enums the same flexibility as other Rust types have. Let's see what this means in practice.

Follow these steps to explore enums:

1. Create a new project with cargo new enums --lib and open this folder...

Functional languages typically don't have a concept of null for the simple reason that it's always a special case. If you strictly follow functional principles, each input must have a workable output—but what is null? Is it an error? Or within normal operating parameters, but a negative result?

As a legacy feature, null has been around since C/C++, when a pointer could actually point to the (invalid) address, 0. However, many new languages try to move away from that. Rust does not have null, and no return value as a normal case with the Option type. The case of error is covered by the Result type, to which we dedicated an entire chapter, Chapter 5, Handling Errors and Other Results.

As shown in the previous recipe, pattern matching is very useful with enums. However, there is more! Pattern matching is a construct that originates in functional languages and curtails much of the choice between conditional branches and the assignment of properties in struct that commonly follows. These steps are taken at once, reducing the amount of code on the screen and creating something akin to a higher-order switch-case statement.

Just a few steps need to be followed in order to learn more about pattern matching:

1. Create a new binary project using cargo new pattern-matching. This time, we'll run an actual executable! Again, open the project using Visual...

The true power of a great language is the way in which it lets the programmer integrate with types in the standard library and around the general ecosystem. One way to do this is the iterator pattern: defined by the Gang of Four in their book Design Patterns (Addison-Wesley Professional, 1994), an iterator is an encapsulation of a pointer moving through a collection. Rust provides a range of implementations on top of the Iterator trait. Let's see how we can leverage that power with only a few lines of code.

We will build an iterator for the linked list we built in an earlier recipe. We recommend either using the Chapter01/testing project or walking with us through construction...

While in the previous recipe we discussed implementing a custom iterator, it's now time to make use of the functions they provide. Iterators can transform, filter, reduce, or simply convert the underlying elements in a single go, thereby making it a very efficient endeavor.

First, create a new project using cargo new iteration --lib and add the following to the newly created Cargo.toml file in the project's directory:

[dev-dependencies]
rand = "^0.5"

This adds a dependency to the rand (https://github.com/rust-random/rand) crate to the project, which will be installed upon running cargo test the first time. Open the entire project (or the src...

unsafe is a concept in Rust where some compiler safety mechanisms are turned off. These superpowers bring Rust closer to C's abilities to manipulate (almost) arbitrary parts of the memory. unsafe itself qualifies a scope (or function) to be able to use these four superpowers (from https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html ):

• Dereference a raw pointer.
• Call an unsafe function or method.
• Access or modify a mutable static variable.
• Implement an unsafe trait.

In most projects, unsafe is only required for using the FFI (short for Foreign Function Interface) because it's outside of the borrow checker's reach. Regardless, in this recipe, we are going to explore some unsafe ways to read memory.

Ownership and borrowing are fundamental concepts in Rust; they are the reason no runtime garbage collection is required. As a quick primer: how do they work? In short: scopes. Rust (and many other languages) use (nested) scopes to determine the validity of a variable, so it cannot be used outside of the scope (like a function). In Rust, these scopes own their variables, so they will be gone after the scope finishes. In order for the program to move around values, it can transfer ownership to a nested scope or return it to the parent scope.

For temporary transfers (and multiple viewers), Rust has borrowing, which creates a reference back to the owned value. However, these references are less powerful, and sometimes more complex to maintain (for example, can the reference outlive the original value?), and they are probably the reason why the compiler complains...

Sharing ownership is great for read-only data. However, mutability is sometimes required, and Rust provides a great way to achieve this. If you recall the rules of ownership and borrowing, if there is a mutable reference, it has to be the only reference to avoid anomalies.

This is typically where the borrow checker comes in: at compile time, it makes sure that the condition holds true. This is where Rust introduces the pattern of interior mutability. By wrapping the data into a RefCell or Cell-type object, immutable and mutable access can be handed out dynamically. Let's see how this works in practice.

Create a new library project using cargo new --lib mut-shared-ownership and open...

Lifetimes are common in many languages and typically decide whether a variable is available outside the scope. In Rust, the situation is a bit more complicated thanks to the borrowing and ownership model that extensively uses lifetimes and scopes to automatically manage memory. Instead of reserving memory and cloning stuff into it, we developers want to avoid the inefficiencies and potential slowdowns this causes with references. However, this leads down a tricky path because, as the original value goes out of scope, what happens to the reference?

Since the compiler cannot infer this information from code, you have to help it and annotate the code so it can go and check for proper usage. Let's see what this looks like.

When building a complex architecture, prerequisite behavior is very common. In Rust, this means that we cannot build either generic or other types without requiring them to conform to some prior behavior, or, in other words, we need to be able to specify which traits are required. Trait bounds are one way of doing that – and you have seen multiple instances of this already, even if you have skipped many recipes so far.

Follow these steps to learn more about traits:

1. Create a new project using cargo new trait-bounds and open it in your favorite editor.
2. Edit src/main.rs to add the following code, where we can easily print a variable's debug format since an implementation...

Rust's function overloading is a bit more exotic than in other languages. Instead of redefining the same function with a different type signature, you can achieve the same result by specifying the actual types for a generic implementation. Generics are a great way to provide more general interfaces and are not too complex to implement thanks to helpful compiler messages.

In this recipe, we are going to implement a dynamic array (such as Vec<T>) in a generic way.

Learn how to use generics in just a few steps:

1. Start off by creating a new library project with cargo new generics --lib and open the project folder in Visual Studio Code.
2. A dynamic array is a data structure...