
M04 Zero Cost
- 803 installs
- 1.3k repo stars
- Updated May 24, 2026
- zhanghandong/rust-skills
This is a copy of m04-zero-cost by actionbook - installs and ranking accrue to the original listing.
m04-zero-cost is a Rust agent skill that helps developers choose between generics and trait objects for zero-cost abstractions for engineers who hit trait bound, type mismatch, and method resolution errors during polymor
About
m04-zero-cost is a Rust language mechanics skill from zhanghandong/rust-skills focused on zero-cost abstractions and the core question of compile-time versus runtime polymorphism. Before picking generics or trait objects, the skill prompts whether the concrete type is known at compile time, whether a heterogeneous collection is required, and what performance priority applies. It maps common compiler errors—including E0277 trait bound not satisfied, E0308 type mismatches, and E0599 missing methods—to design questions instead of shallow error explanations. Triggers cover generics, traits, impl Trait, dyn, where clauses, monomorphization, static dispatch, and dynamic dispatch keywords in English and Chinese. Developers reach for m04-zero-cost when Rust fights back on trait bounds and they need a decision framework for static versus dynamic dispatch without abandoning zero-cost guarantees.
- Translates Rust errors E0277, E0308, E0599, E0038 into design-level questions about abstraction
- Guides decision between compile-time generics (static dispatch) and runtime trait objects (dynamic dispatch)
- 3-step thinking prompt covering needed abstraction, type knowledge timing, and performance trade-offs
- Maps concrete Rust patterns: trait bounds, impl Trait, monomorphization, dyn, where clauses
- Includes bilingual triggers for English and Chinese Rust learners
M04 Zero Cost by the numbers
- 803 all-time installs (skills.sh)
- +7 installs in the week ending Jul 28, 2026 (Skillselion tracking)
- Security screen: MEDIUM risk (skills.sh audit)
- Data as of Jul 28, 2026 (Skillselion catalog sync)
npx skills add https://github.com/zhanghandong/rust-skills --skill m04-zero-costAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 803 |
|---|---|
| repo stars | ★ 1.3k |
| Security audit | 3 / 3 scanners passed |
| Last updated | May 24, 2026 |
| Repository | zhanghandong/rust-skills ↗ |
When should Rust code use generics versus trait objects?
Correctly choose between generics and trait objects in Rust so they get zero-cost abstractions without fighting the compiler.
Who is it for?
Rust developers debugging trait bound and dispatch errors who need a structured generics-versus-trait-objects decision framework.
Skip if: Beginners learning Rust syntax basics or teams writing code with no traits, generics, or polymorphism requirements.
When should I use this skill?
Rust compilation fails with E0277, E0308, E0599, or the developer debates generics, dyn, impl Trait, or monomorphization.
What you get
Trait-bound designs using generics or dyn Trait with justified static or dynamic dispatch and resolved compiler errors.
- Polymorphism design decisions
- Resolved trait-bound code patterns
By the numbers
- Maps 3 Rust compiler errors: E0277, E0308, E0599
- Layer 1 language-mechanics skill in rust-skills series
Files
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
// 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>) { } // ownedError 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: Sizedbound - Doesn't return
Self - Doesn't have generic methods
- Uses
where Self: Sizedfor 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 |
Related skills
How it compares
Pick m04-zero-cost over generic Rust cheat sheets when compiler errors force a generics-versus-dyn decision with zero-cost abstraction tradeoffs.
FAQ
Which Rust errors does m04-zero-cost address?
m04-zero-cost addresses E0277 trait bound not satisfied, E0308 type mismatches, and E0599 method resolution failures. The skill reframes each error as a compile-time versus runtime polymorphism design question.
How does m04-zero-cost choose generics or trait objects?
m04-zero-cost asks whether types are known at compile time, whether heterogeneous collections are needed, and what performance priority applies. Generics favor static monomorphized dispatch; dyn trait objects favor runtime polymorphism.
Is M04 Zero Cost safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.