Type System Design

Core Question

What invariants should the type system enforce?

Every time you reach for a String where an enum would work, a u64 where a UserId would be clearer, or a runtime check where a compile-time guarantee is possible — ask whether the type system can do the work for you.

The Rust type system is powerful enough to catch entire categories of bugs at compile time. The question is always: is the added type complexity worth the guarantee?

Error → Design Question

Quick Decisions

Static vs Dynamic Dispatch

Need different concrete types in the same collection?
├── Yes → dyn Trait (dynamic dispatch)
│   └── Box<dyn Trait> for owned, &dyn Trait for borrowed
└── No → impl Trait or generics (static dispatch)
    └── Monomorphized: zero overhead, larger binary

Object safety requires: no Self: Sized bound, no generic methods, no Self in return position (without -> Box<dyn Trait>).

Newtype Pattern

Zero-cost wrapper that adds type safety:

#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
pub struct UserId(u64);

#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
pub struct OrderId(u64);

// These are now distinct types — can't mix them
fn get_order(user: UserId, order: OrderId) -> Order { ... }

Parse-Don't-Validate

Validate at construction, trust the type afterward:

pub struct Email(String);

impl Email {
    pub fn new(s: &str) -> Result<Self, EmailError> {
        if s.contains('@') && s.len() > 3 {
            Ok(Email(s.to_string()))
        } else {
            Err(EmailError::Invalid(s.to_string()))
        }
    }

    pub fn as_str(&self) -> &str { &self.0 }
}

// Once you have an Email, it's valid — no re-checking needed
fn send(to: &Email, body: &str) { ... }

Usage Scenarios

Scenario 1: "I have a function taking two u64 parameters and callers keep swapping them" → Wrap each in a newtype: UserId(u64) and OrderId(u64). Zero runtime cost, compiler catches swaps.

Scenario 2: "Should I use Box<dyn Handler> or generics for my plugin system?" → If you need a Vec<Box<dyn Handler>> with different concrete types, use dynamic dispatch. If each call site uses one known type, use impl Handler for zero-cost dispatch.

Scenario 3: "I'm getting E0277 'the trait bound is not satisfied' everywhere" → Don't just add bounds. Check: is the bound on the right level (impl block vs struct)? Are you constraining too early? Bounds on the struct definition propagate everywhere — prefer bounds on impl blocks.

Reference Files

Cross-References