home / skills / zhanghandong / rust-skills / m04-zero-cost

m04-zero-cost skill

safe

This skill helps you choose between generics and trait objects for zero-cost abstraction in Rust, optimizing performance and flexibility.

npx playbooks add skill zhanghandong/rust-skills --skill m04-zero-cost

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

4.6 KB

---
name: m04-zero-cost
description: "CRITICAL: Use for generics, traits, zero-cost abstraction. Triggers: E0277, E0308, E0599, generic, trait, impl, dyn, where, monomorphization, static dispatch, dynamic dispatch, impl Trait, trait bound not satisfied, 泛型, 特征, 零成本抽象, 单态化"
user-invocable: false
---

# 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:

1. **What abstraction is needed?**
   - Same behavior, different types → trait
   - Different behavior, same type → enum
   - No abstraction needed → concrete type

2. **When is type known?**
   - Compile time → generics (static dispatch)
   - Runtime → trait objects (dynamic dispatch)

3. **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

```rust
// 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 |

Overview

This skill helps Rust developers choose between generics, traits, and trait objects to achieve zero-cost abstractions. It frames compiler errors as design prompts and provides decision rules for static vs dynamic dispatch, object safety, and common anti-patterns. Use it to turn type errors into architecture questions rather than quick fixes.

How this skill works

The skill inspects common Rust errors (E0277, E0308, E0599, E0038) and maps them to design questions: should you add a trait bound, change types, or switch dispatch strategy? It summarizes trade-offs (static vs dynamic dispatch, monomorphization cost, vtable overhead) and gives quick patterns and fixes for returning, passing, and collecting polymorphic values. It also highlights object safety constraints and anti-patterns to avoid.

When to use it

When compiler shows E0277 (trait bound not satisfied) and you need to reassess abstraction level
When E0308 (type mismatch) indicates competing concrete types or wrong generic parameters
When E0599 (method not found) suggests missing trait imports or wrong trait choice
When designing for performance-critical code and you must decide between generics and dyn Trait
When you need heterogeneous collections, plugin systems, or to reduce compile-time bloat

Best practices

Ask whether the abstraction belongs at the domain level before adding bounds
Prefer generics (static dispatch) when types are known and performance matters
Use dyn Trait for open or runtime-determined sets and plugin architectures
Use enums for a closed set of different behaviors to avoid indirection
Keep traits object-safe if you expect dynamic dispatch; move non-object-safe methods behind where Self: Sized

Example use cases

Fixing E0277 by deciding if the trait is the right abstraction or the function should accept a concrete type
Choosing impl Trait or generic parameters when returning different concrete types with same behavior
Replacing Box<dyn Trait> with generics for hot inner loops to remove vtable cost
Designing a plugin interface where implementations are unknown at compile time and dyn Trait is appropriate
Converting a heterogeneous Vec<Box<dyn Trait>> to an enum when set of types is closed for better simplicity and no allocation overhead

FAQ

When should I prefer impl Trait over Box<dyn Trait>?

Use impl Trait when callers can accept a single concrete type per call site and you want zero runtime cost; use Box<dyn Trait> when the concrete type is unknown or varies at runtime.

How do I resolve object-safety errors (E0038)?

Remove methods that return Self or are generic, or split the trait: keep object-safe parts for dyn use and put sized-only helpers behind where Self: Sized.