Abstraction Through Unit and Trait Impl

The Unit Type and Type System Uniformity

The Unit type () introduced in the Expression-Based Programming chapter is a crucial element supporting the uniformity of Rust's type system. Let's first look deeper at the Unit type's nature before entering the world of traits.

What the Unit Type Really Is

The Unit type () is "a type with only one possible value," and that sole value is also written (). It's identical to an empty tuple:

let unit: () = ();

// A 0-element tuple = the Unit type
let also_unit: () = ();

The reason the Unit type matters is that it lets the type system treat "nothing" as "something."

The Decisive Difference from void

C/C++'s void and Rust's () are similar but fundamentally different:

// C: void is a special entity that "isn't a type"
void foo();           // OK
void* ptr;            // OK (usable as a generic pointer despite not being a type)
// void x;            // NG: can't create a variable of type void
// sizeof(void);      // Undefined behavior (1 in GCC extensions)

// Rust: () is an ordinary type
fn foo() -> () { () }   // OK
let x: () = ();          // OK: can create a variable of the Unit type
std::mem::size_of::<()>() // 0 (zero-sized, but a legitimate type)

// You can even make a Vec<()>
let v: Vec<()> = vec![(), (), ()];
assert_eq!(v.len(), 3);

() is a legitimate type -- you can bind it to a variable, pass it as a generic type parameter. This prevents special cases from arising in the type system.

The Generalization the Unit Type Enables

The Unit type's true value lies in naturally expressing the "has no value" case within generic structures:

// Result<(), Error>: an operation with no value on success
fn delete_file(path: &str) -> Result<(), std::io::Error> {
    std::fs::remove_file(path)
}

// HashMap<String, ()>: no value -> effectively equivalent to HashSet
use std::collections::HashMap;
let mut set: HashMap<String, ()> = HashMap::new();
set.insert("key".to_string(), ());

// Option<()>: expressing only "whether something exists"
let exists: Option<()> = Some(());

Result<(), E> is an extremely common pattern in Rust. It expresses "success/failure exists, but there's no data to return on success" without introducing a dedicated type.

The Unit Type and Traits

The Unit type is an ordinary type that can implement traits:

// You can implement Display for () (it's already implemented in the standard library)
// () implements Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Hash, Default

let a: () = Default::default();  // The default value of () is ()
assert_eq!((), ());               // PartialEq works

Because the Unit type implements these traits, you can pass () to generic functions with trait bounds like T: Default or T: Eq. No holes in the type system.

---

What Are Traits

In Bitterless Rust, we introduced #[derive(Debug, Clone, PartialEq)] as "boilerplate magic." This chapter accurately explains the trait mechanism behind it.

A trait defines an interface of behaviors that a type must satisfy. It's similar to Java's interface or Haskell's type classes, but Rust's traits have their own powerful characteristics.

trait Greet {
    fn greet(&self) -> String;
}

This definition means "a type implementing the Greet trait must have a greet method."

Implementing Traits (impl)

Traits can be implemented on any type using the impl Trait for Type syntax:

struct User {
    name: String,
}

impl Greet for User {
    fn greet(&self) -> String {
        format!("Hello, I'm {}!", self.name)
    }
}

struct Bot {
    id: u32,
}

impl Greet for Bot {
    fn greet(&self) -> String {
        format!("Beep boop, I'm Bot #{}.", self.id)
    }
}

User and Bot are completely different structs, but both implement the Greet trait and therefore have a greet() method.

Standard Library Traits: Abstracting Built-in Features

What's particularly wonderful about Rust's design is that built-in language features are abstracted through traits. Things that many languages implement as hardcoded compiler behavior are explicitly defined as traits in Rust, and can be implemented on user-defined types in exactly the same way.

Display: String Representation

When you display a value with {} in println!("{}", x), the Display trait is called internally:

use std::fmt;

struct Point {
    x: f64,
    y: f64,
}

impl fmt::Display for Point {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        write!(f, "({}, {})", self.x, self.y)
    }
}

fn main() {
    let p = Point { x: 1.0, y: 2.0 };
    println!("{}", p);  // (1.0, 2.0)

    // Implementing Display also automatically enables .to_string()
    let s: String = p.to_string();
}

In Java, the toString() method is defined on the Object class and implicitly inherited by all objects. In Rust, Display is a trait that must be explicitly implemented. Without the implementation, {} display won't work. This embodies Rust's design philosophy of eliminating "implicit behavior."

The Debug trait (used with {:?}) is similar -- #[derive(Debug)] is merely a macro that auto-generates a Debug trait implementation.

Drop: Resource Cleanup

When a value goes out of scope, Rust automatically calls the Drop trait's drop method:

struct FileHandle {
    name: String,
}

impl Drop for FileHandle {
    fn drop(&mut self) {
        println!("Closing file: {}", self.name);
    }
}

fn main() {
    let _f = FileHandle { name: String::from("data.txt") };
    println!("File opened");
    // <- Here _f goes out of scope, and drop is automatically called
}
// Output:
// File opened
// Closing file: data.txt

This is similar to C++'s RAII (Resource Acquisition Is Initialization) pattern, but in Rust it's explicitly defined as the Drop trait. File handles, network sockets, locks -- resource cleanup for all of these is handled uniformly as Drop trait implementations.

The combination of the ownership system and the Drop trait structurally prevents resource leaks.

Copy and Clone: Value Duplication

Rust has two traits related to value duplication:

// Copy: implicit bitwise copy
// Automatically copied during assignment or passing to functions
#[derive(Copy, Clone)]
struct Point {
    x: f64,
    y: f64,
}

// Clone: explicit deep copy
// Requires calling the .clone() method
#[derive(Clone)]
struct Buffer {
    data: Vec<u8>,
}

The distinction between Copy and Clone is central to Rust's ownership system:

• Copy: Can only be implemented for types that can be fully duplicated via bitwise copy. All primitive types like i32, f64, bool implement Copy. Values of Copy types are implicitly copied during assignment or function calls (ownership doesn't move)
• Clone: Requires an explicit .clone() call. May involve costly operations like deep copying of heap memory. String and Vec<T> implement Clone but not Copy

Copy is a subtrait of Clone (Copy: Clone), so a type implementing Copy must also implement Clone.

This design clearly distinguishes "cheap copies" from "expensive copies" at the type level. When we said ".clone() solves it" in Bitterless Rust, we were calling the Clone trait's method.

PartialEq and Eq: Equality Comparison

#[derive(PartialEq)]
struct Point {
    x: f64,
    y: f64,
}

fn main() {
    let a = Point { x: 1.0, y: 2.0 };
    let b = Point { x: 1.0, y: 2.0 };
    assert!(a == b);  // PartialEq provides the == operator
}

The reason PartialEq and Eq are separated has a mathematical background:

• PartialEq: Partial equivalence relation. a == a doesn't have to always be true. f64 implements only PartialEq (not Eq) because NaN != NaN
• Eq: Equivalence relation (satisfies reflexivity). a == a is always true. i32, String, bool, etc. implement Eq

Eq is a subtrait of PartialEq (Eq: PartialEq) and doesn't define additional methods. However, it functions as a type-level constraint -- for example, HashMap keys require Eq.

Similarly, there are PartialOrd and Ord:

• PartialOrd: Partial order. Incomparable pairs can exist (f64's NaN)
• Ord: Total order. All pairs are comparable

Add, Sub, Mul, ...: Operator Overloading

Rust's operators are defined as traits:

use std::ops::Add;

#[derive(Debug, Clone, Copy)]
struct Vec2 {
    x: f64,
    y: f64,
}

impl Add for Vec2 {
    type Output = Vec2;

    fn add(self, rhs: Vec2) -> Vec2 {
        Vec2 {
            x: self.x + rhs.x,
            y: self.y + rhs.y,
        }
    }
}

fn main() {
    let a = Vec2 { x: 1.0, y: 2.0 };
    let b = Vec2 { x: 3.0, y: 4.0 };
    let c = a + b;  // Calls the Add trait's add method
    println!("{:?}", c); // Vec2 { x: 4.0, y: 6.0 }
}

The + operator is the Add trait, - is Sub, * is Mul, / is Div, % is Rem, unary - is Neg -- they're all traits.

And more:

Operator/Operation	Trait
[] (index access)	Index / IndexMut
* (dereference)	Deref / DerefMut
() (function call)	Fn / FnMut / FnOnce
for x in ...	IntoIterator
.. (Range)	RangeBounds

The fact that all of these are defined as traits is significant. User-defined types can use the same operators with the same syntax as built-in types. It's provided uniformly as a language mechanism, not as special compiler treatment.

Traits as Zero-Cost Abstraction

Traits are an abstraction mechanism, but as covered in the Performance chapter, monomorphization means no runtime cost:

fn print_all(items: &[impl std::fmt::Display]) {
    for item in items {
        println!("{}", item);
    }
}

impl Display is expanded to concrete types at compile time, so there's zero overhead from indirect calls through the Display trait.

Default Implementations

Traits can have default method implementations:

trait Summary {
    fn title(&self) -> String;

    // Default implementation: can be overridden
    fn summarize(&self) -> String {
        format!("{} - (Read more...)", self.title())
    }
}

struct Article {
    title: String,
    content: String,
}

impl Summary for Article {
    fn title(&self) -> String {
        self.title.clone()
    }
    // summarize uses the default implementation as-is
}

Default implementations can call other trait methods, enabling designs that provide rich functionality with minimal implementation.

The Orphan Rule

There's an important constraint on trait implementations: You cannot write impl Trait for Type unless either the trait or the type is defined in your own crate. This is called the Orphan Rule.

// OK: Implementing an external trait on your own type
impl fmt::Display for MyType { ... }

// OK: Implementing your own trait on an external type
impl MyTrait for Vec<i32> { ... }

// NG: Implementing an external trait on an external type
// impl fmt::Display for Vec<i32> { ... }  // Compile error

This constraint prevents different crates from implementing the same trait for the same type in contradictory ways. While it can feel inconvenient, it's an essential rule for maintaining ecosystem-wide consistency.

Summary

The beauty of Rust's trait system can be summarized as follows:

1. Built-in features abstracted through traits: Display (Display), cleanup (Drop), duplication (Copy/Clone), comparison (Eq/PartialEq), operators (Add/Sub/...) are all defined as traits
2. Generalization to user-defined types: The same traits as built-in types can be implemented on your types, used with the same syntax
3. Zero cost: Static dispatch and monomorphization mean zero runtime cost for abstractions
4. Explicitness: No implicit behavior -- all capabilities a type has are explicitly stated as trait implementations

This design forms the core of Rust's type system: describing "what behaviors a type has" in the unified language of traits, and verifying it at compile time.