M04 Zero Cost
Guide generics versus trait objects and trait-bound fixes when Rust compile errors block backend or CLI work.
Overview
M04 zero-cost is an agent skill most often used in Build (also Ship review, Operate iteration) that guides generics, traits, and zero-cost abstraction choices when Rust compiler errors signal wrong polymorphism level.
Install
npx skills add https://github.com/actionbook/rust-skills --skill m04-zero-costWhat is this skill?
- Maps compiler errors E0277, E0308, E0599, E0038 to design questions—not blind bound patching
- Layer-1 language mechanics: static vs dynamic dispatch decision tree
- Thinking prompts for trait vs enum vs concrete type before adding where clauses
- Triggers on generics, impl Trait, dyn, monomorphization, and bilingual Rust/中文 keywords
- 4 mapped compiler error codes with paired design questions (E0277, E0308, E0599, E0038)
Adoption & trust: 947 installs on skills.sh; 1.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Rust compile errors around trait bounds and dispatch leave you unsure whether to use generics, dyn Trait, or a simpler concrete or enum design.
Who is it for?
Solo Rust builders debugging E0277/E0599-class errors while designing reusable backend or CLI modules.
Skip if: Greenfield Rust tutorials with no type errors yet, or teams wanting automated refactors without design reasoning.
When should I use this skill?
Rust work hits generics, traits, impl Trait, dyn, where clauses, monomorphization, or errors E0277, E0308, E0599, E0038.
What do I get? / Deliverables
You resolve the error with an abstraction level that matches when types are known and your performance versus flexibility trade-offs.
- Documented dispatch and abstraction recommendation tied to the triggering error
- Refactor direction for trait vs enum vs concrete types
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Zero-cost abstraction decisions land first while implementing Rust services, libraries, and performance-sensitive backend code. Backend Rust modules are where trait bounds, monomorphization, and dyn dispatch choices most often surface as E0277/E0599 failures.
Where it fits
Choose generics over dyn Trait for a hot path HTTP handler where the concrete type is fixed at compile time.
Reframe a PR that adds blanket impls so review comments target abstraction level instead of syntax nits.
After a dependency upgrade triggers E0308, decide whether to unify types or split distinct newtypes.
How it compares
Use instead of stacking trait bounds until the compiler accepts code—this skill forces static versus dynamic dispatch intent first.
Common Questions / FAQ
Who is m04-zero-cost for?
Indie developers and small teams using agent-assisted Rust on backends and CLIs who want structured answers to trait and generic compiler failures.
When should I use m04-zero-cost?
During Build when authoring traits and generics; during Ship when review surfaces bound errors; during Operate when refactors reintroduce E0277 or E0038 object-safety issues.
Is m04-zero-cost safe to install?
It is reference procedural knowledge with no prescribed shell or network calls; still review the Security Audits panel on this page before adding any skill to your agent.
SKILL.md
READMESKILL.md - M04 Zero Cost
# 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 method