Advanced Types in Rust

This chapter explores advanced type system features in Rust, focusing on how to leverage the type system to guarantee safety, reduce code repetition, manage dynamically sized data, and handle non-returning control flows. By mastering these patterns, you can write more expressive, robust, and performant Rust applications.

1. The Orphan Rule and the New Type Pattern

In Rust, implementing a trait on a type is governed by the orphan rule. This rule states that you can implement a trait on a type only if either the trait or the type is defined within your local crate.

If you need to implement an external trait on an external type (for example, implementing the Display trait on the standard library's Vec<T>), you must bypass this restriction using the New Type Pattern. This pattern involves creating a new tuple struct that wraps the external type. Because the wrapper struct is defined in your local crate, you can freely implement the external trait on it.

Code Evolution: Implementing Display on Vec<String>

The Naive (Non-Compiling) Approach

Attempting to implement Display directly on Vec<T> fails because both the trait and the type are defined in the standard library:

use std::fmt;

// This will trigger a compiler error (E0117: orphan rule violation)
impl<T> fmt::Display for Vec<T> {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        write!(f, "Vector contents")
    }
}

The Clean New Type Solution

By wrapping Vec<String> in a local tuple struct named Wrapper, we satisfy the orphan rule:

use std::fmt;

// 1. Define a local wrapper tuple struct
struct Wrapper(Vec<String>);

// 2. Implement the external Display trait on the local Wrapper type
impl fmt::Display for Wrapper {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        // Access the inner vector using self.0
        write!(f, "[{}]", self.0.join(", "))
    }
}

fn main() {
    let w = Wrapper(vec![String::from("Rust"), String::from("Go"), String::from("C++")]);
    println!("Languages: {}", w);
}

2. Enhancing Type Safety with New Types

Beyond bypassing the orphan rule, the new type pattern is a powerful tool for preventing semantic errors at compile time. When multiple values share the same underlying primitive representation, it is easy to accidentally pass them to the wrong parameters.

Real-Life Analogy

Imagine a security desk where visitors must present an Age verification card and an Employee ID card. Both cards display numbers, but showing your age card to the employee scanner or vice versa should be rejected by the system.

Code Evolution: Preventing Parameter Mix-ups

The Naive Approach (High Risk of Silent Bugs)

Using raw u32 integers for distinct domain concepts allows developers to accidentally swap arguments without triggering compiler errors:

// Both parameters are raw u32 integers
fn register_employee(age: u32, employee_id: u32) {
    println!("Registering employee ID {} (Age: {})", employee_id, age);
}

fn main() {
    let age: u32 = 30;
    let id: u32 = 9945;

    // Bug: The arguments are swapped, but the compiler allows it!
    register_employee(id, age); 
}

The Type-Safe New Type Solution

Wrapping the primitive types in distinct tuple structs forces the compiler to verify that the correct domain concept is passed to each parameter:

struct Age(pub u32);
struct EmployeeId(pub u32);

fn register_employee_safe(age: Age, employee_id: EmployeeId) {
    println!("Registering employee ID {} (Age: {})", employee_id.0, age.0);
}

fn main() {
    let age = Age(30);
    let id = EmployeeId(9945);

    // This compiles successfully:
    register_employee_safe(age, id);

    // This would fail to compile, preventing a silent production bug:
    // register_employee_safe(id, age); 
}

3. Encapsulation and Abstracting Implementation Details

The new type pattern also serves as a lightweight encapsulation boundary. By wrapping a complex internal data structure inside a public struct, you can expose a clean, simplified public API while hiding the underlying implementation details.

Public API (People Struct)
   |
   | Exposes only defined methods (e.g., add_person)
   v
Internal Implementation (Private HashMap<i32, String>)

Implementation Example: Abstracting a Directory

use std::collections::HashMap;

// Wrap a private HashMap inside the public People struct
pub struct People(HashMap<i32, String>);

impl People {
    // Create a new instance
    pub fn new() -> Self {
        People(HashMap::new())
    }

    // Expose a clean, controlled interface
    pub fn add_person(&mut self, id: i32, name: String) {
        self.0.insert(id, name);
    }

    // The consumer has no direct access to the underlying HashMap methods
}

Using this pattern, you can change the internal storage mechanism (e.g., swapping the HashMap for a BTreeMap or a database connection) in the future without breaking any external code that relies on the People type.

4. Type Aliases: Synonyms vs. New Types

Rust allows you to declare Type Aliases using the type keyword. It is critical to understand that a type alias is not a new type; it is merely a synonym for an existing type.

type Kilometers = i32;

Because Kilometers is a synonym and not a distinct type, the compiler treats it identically to its underlying type. This means you lose the compile-time safety guarantees provided by the new type pattern.

Code Example: Mixing Aliased Types

type Kilometers = i32;

fn main() {
    let x: i32 = 5;
    let y: Kilometers = 10;

    // This compiles! No type safety is enforced between i32 and Kilometers.
    let total = x + y;
    println!("Total: {}", total);
}

Comparison: New Type vs. Type Alias

5. Reducing Code Repetition with Type Aliases

The primary use case for type aliases is to simplify long, complex type signatures that are repeated throughout a codebase. This is particularly common when working with complex closures, smart pointers, or nested generic types.

Code Evolution: Simplifying Complex Types

The Naive Approach (Repetitive and Hard to Read)

Writing out long closure signatures repeatedly makes code difficult to maintain:

fn register_callback(f: Box<dyn Fn() + Send + 'static>) {
    // ...
}

fn execute_callback(f: Box<dyn Fn() + Send + 'static>) {
    // ...
}

The Clean Solution using Type Aliases

By defining a type alias, we make the code significantly cleaner and easier to read. In computer science, a Thunk is a term used for code that will be evaluated at some later point in time. This makes it an excellent name for an aliased closure:

// Define a type alias for the complex closure signature
type Thunk = Box<dyn Fn() + Send + 'static>;

fn register_callback(f: Thunk) {
    // ...
}

fn execute_callback(f: Thunk) {
    // ...
}

6. The Never Type (!) and Control Flow Unification

Rust features a special type named the Never Type, which is represented by an exclamation point (!). In type theory, this is known as the empty type because it has no values. It indicates that an expression or function will never return a value to its caller.

The Problem of Match Arm Type Unification

In Rust, all arms of a match expression must evaluate to the exact same type. Consider this common pattern from the classic guessing game:

let guess = "42";

let guess: u32 = match guess.trim().parse() {
    Ok(num) => num,     // Evaluates to u32
    Err(_) => continue, // What type does 'continue' evaluate to?
};

How is this code valid if the Ok arm returns a u32 and the Err arm executes a continue statement?

The Solution: The Never Type

The continue statement has the type !. Because ! can be coerced into any other type, Rust's compiler can unify the types of both match arms to u32.

If the program enters the Err arm, the continue statement immediately transfers control back to the top of the loop. Because control never reaches the assignment of guess, no value is ever assigned, preserving type safety.

7. The Never Type in Standard Library Patterns

The never type is utilized extensively across the Rust standard library to handle operations that diverge (i.e., operations that terminate the program or loop indefinitely).

1. The panic! Macro

The Option::unwrap method retrieves the inner value of a Some variant, but panics if it encounters a None variant. Under the hood, this is made possible because panic! returns the never type:

impl<T> Option<T> {
    pub fn unwrap(self) -> T {
        match self {
            Some(val) => val, // Evaluates to T
            None => panic!("Called Option::unwrap() on a None value"), // Evaluates to !
        }
    }
}

Because panic! evaluates to !, it can be coerced into type T, allowing the entire match expression to compile successfully.

2. Infinite Loops

An infinite loop without a break statement never terminates, meaning its expression evaluates to !:

fn infinite_loop() -> ! {
    loop {
        println!("This loop runs forever!");
    }
}

Note: If a loop contains a break statement, it can return a value (or ()), meaning its type is no longer !.

RUST

Copy

let x = loop {
    break 5; // The loop expression now evaluates to i32, not !
};

8. Dynamically Sized Types (DSTs) and the Size Problem

Rust needs to know how much memory to allocate for a value at compile time. However, certain types have sizes that can only be determined at runtime. These are known as Dynamically Sized Types (DSTs) or Unsized Types.

The Problem with str

The bare string slice str is a dynamically sized type. We cannot know the length of a string slice until the program runs.

The Non-Compiling Code

Attempting to declare local variables of type str directly results in a compilation error:

fn main() {
    // This will fail to compile!
    let s1: str = "Hello there";
    let s2: str = "How are you?";
}

The Compiler Error

Because all local variables must have a statically known size, Rust cannot allocate space on the stack for a raw str.

9. The Golden Rule of DSTs: Fat Pointers

To work with dynamically sized types, Rust enforces a strict rule: DSTs must always be placed behind a pointer.

Instead of using str directly, we use the borrowed version: &str.

A &str is a fat pointer. It contains two pieces of metadata:

1. The memory address pointing to the actual string data.
2. The length of the string.

Because both the address and the length are of type usize, their sizes are known at compile time. Therefore, the fat pointer itself has a statically known size and can be safely stored on the stack.

Alternative Pointers for DSTs

You can place dynamically sized types behind other smart pointers as well:

// Storing a dynamically sized string slice on the heap
let boxed_str: Box<str> = Box::from("Hello World");

// Storing a dynamically sized string slice inside a reference-counted pointer
use std::rc::Rc;
let rc_str: Rc<str> = Rc::from("Hello World");

Traits as DSTs

Every trait is a dynamically sized type. When creating trait objects (e.g., dyn Draw), you must place them behind a pointer (such as &dyn Draw or Box<dyn Draw>) for the exact same reason: the compiler does not know the size of the concrete struct implementing the trait at compile time.

10. The Sized Trait and Relaxing Generic Bounds

To manage sized and unsized types, Rust uses the Sized auto-trait.

• The Sized Trait: Automatically implemented by the compiler for any type whose size is known at compile time (e.g., i32, f64, struct, &str).
• Implicit Bounds: By default, Rust implicitly adds a Sized bound to all generic functions.

Code Evolution: Relaxing the Sized Bound

The Default Implicit Bound

When you write a generic function:

fn my_generic_function<T>(t: T) {
    // ...
}

Rust implicitly treats it as:

fn my_generic_function<T: Sized>(t: T) {
    // ...
}

This means the function will only accept types whose size is known at compile time.

Relaxing the Bound with ?Sized

If you want a generic function to accept both sized and unsized types (such as str or trait objects), you must use the special ?Sized syntax (read as "maybe sized"):

// T can be Sized or Unsized
fn print_value<T: ?Sized>(t: &T) {
    // ...
}

Note: Because T might not be sized, we can no longer pass it by value (t: T). We must put it behind a pointer, which is why the parameter type is changed to &T.

Summary and Key Takeaways

• The Orphan Rule prevents you from implementing external traits on external types. You can bypass this restriction using the New Type Pattern by wrapping the external type in a local tuple struct.
• The New Type Pattern enhances type safety by wrapping primitive types (like u32) in distinct domain types (like Age and EmployeeId), catching argument mix-ups at compile time.
• Type Aliases (type Kilometers = i32;) are merely synonyms for existing types. They do not create new types, meaning they offer no additional type safety.
• Reducing Repetition is the primary use case for type aliases, allowing you to replace long, complex type signatures (like nested closures or smart pointers) with clean, readable names.
• The Never Type (!) represents expressions that will never return a value, such as continue, panic!, or infinite loops.
• Type Unification allows Rust to compile match expressions where one arm diverges (returns !) and the other returns a concrete type (like u32), because ! can be coerced into any other type.
• Dynamically Sized Types (DSTs) are types whose size is only known at runtime (e.g., str or dyn Trait).
• The Golden Rule of DSTs is that they must always be placed behind a pointer (like &T, Box<T>, or Rc<T>), turning them into fat pointers that store both the memory address and the size metadata.
• The ?Sized Trait Bound relaxes Rust's default assumption that all generic parameters must have a statically known size, allowing generic functions to accept unsized types when passed behind a pointer.