m04-zero-cost

SKILL.md

Zero-Cost Abstraction

Layer 1: Language Mechanics

Core Question

Do we need compile-time or runtime polymorphism?

Before choosing between generics and trait objects:

Is the type known at compile time?

Is a heterogeneous collection needed?

What's the performance priority?

Error → Design Question

Error
Don't Just Say
Ask Instead

E0277
"Add trait bound"
Is this abstraction at the right level?

E0308
"Fix the type"
Should types be unified or distinct?

E0599
"Import the trait"
Is the trait the right abstraction?

E0038
"Make object-safe"
Do we really need dynamic dispatch?

Thinking Prompt

Before adding trait bounds:

What abstraction is needed?

Same behavior, different types → trait

Different behavior, same type → enum

No abstraction needed → concrete type

When is type known?

Compile time → generics (static dispatch)

Runtime → trait objects (dynamic dispatch)

What's the trade-off priority?

Performance → generics

Compile time → trait objects

Flexibility → depends

Trace Up ↑

When type system fights back:

E0277 (trait bound not satisfied)
    ↑ Ask: Is the abstraction level correct?
    ↑ Check: m09-domain (what behavior is being abstracted?)
    ↑ Check: m05-type-driven (should use newtype?)

Persistent Error
Trace To
Question

Complex trait bounds
m09-domain
Is the abstraction right?

Object safety issues
m05-type-driven
Can typestate help?

Type explosion
m10-performance
Accept dyn overhead?

Trace Down ↓

From design to implementation:

"Need to abstract over types with same behavior"
    ↓ Types known at compile time → impl Trait or generics
    ↓ Types determined at runtime → dyn Trait

"Need collection of different types"
    ↓ Closed set → enum
    ↓ Open set → Vec<Box<dyn Trait>>

"Need to return different types"
    ↓ Same type → impl Trait
    ↓ Different types → Box<dyn Trait>

Quick Reference

Pattern
Dispatch
Code Size
Runtime Cost

fn foo<T: Trait>()
Static
+bloat
Zero

fn foo(x: &dyn Trait)
Dynamic
Minimal
vtable lookup

impl Trait return
Static
+bloat
Zero

Box<dyn Trait>
Dynamic
Minimal
Allocation + vtable

Syntax Comparison

// Static dispatch - type known at compile time
fn process(x: impl Display) { }      // argument position
fn process<T: Display>(x: T) { }     // explicit generic
fn get() -> impl Display { }         // return position

// Dynamic dispatch - type determined at runtime
fn process(x: &dyn Display) { }      // reference
fn process(x: Box<dyn Display>) { }  // owned

Error Code Reference

Error
Cause
Quick Fix

E0277
Type doesn't impl trait
Add impl or change bound

E0308
Type mismatch
Check generic params

E0599
No method found
Import trait with use

E0038
Trait not object-safe
Use generics or redesign

Decision Guide

Scenario
Choose
Why

Performance critical
Generics
Zero runtime cost

Heterogeneous collection
dyn Trait
Different types at runtime

Plugin architecture
dyn Trait
Unknown types at compile

Reduce compile time
dyn Trait
Less monomorphization

Small, known type set
enum
No indirection

Object Safety

A trait is object-safe if it:

Doesn't have Self: Sized bound

Doesn't return Self

Doesn't have generic methods

Uses where Self: Sized for non-object-safe methods

Anti-Patterns

Anti-Pattern
Why Bad
Better

Over-generic everything
Compile time, complexity
Concrete types when possible

dyn for known types
Unnecessary indirection
Generics

Complex trait hierarchies
Hard to understand
Simpler design

Ignore object safety
Limits flexibility
Plan for dyn if needed

Related Skills

When
See

Type-driven design
m05-type-driven

Domain abstraction
m09-domain

Performance concerns
m10-performance

Send/Sync bounds
m07-concurrency