m04-zero-cost
Evaluates trait bounds and monomorphization strategies to help developers choose between generics and trait objects based on performance and compile-time needs.
Install
mkdir -p .claude/skills/m04-zero-cost && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/8213" && unzip -o skill.zip -d .claude/skills/m04-zero-cost && rm skill.zipInstalls to .claude/skills/m04-zero-cost
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
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, 泛型, 特征, 零成本抽象, 单态化Key capabilities
- →Evaluate trait bounds
- →Decide dispatch strategies
- →Resolve compiler errors
- →Design polymorphic interfaces
How it works
The skill provides a framework for choosing between static and dynamic dispatch based on performance and flexibility needs.
Inputs & outputs
When to use m04-zero-cost
- →Refactoring trait bounds to improve performance
- →Deciding between static and dynamic dispatch
- →Resolving E0277, E0308, and E0599 compiler errors
- →Designing polymorphic interfaces
About this skill
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: 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 |
When not to use it
- →Over-genericizing simple code
- →Using dyn for known types
Limitations
- →Static dispatch increases binary size
- →Dynamic dispatch adds vtable overhead
How it compares
It focuses on the trade-offs of zero-cost abstractions rather than just syntax.
Compared to similar skills
m04-zero-cost side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| m04-zero-cost (this skill) | 0 | 6mo | No flags | Intermediate |
| organize-modules | 1 | 2mo | Review | Intermediate |
| m06-error-handling | 1 | 6mo | Review | Intermediate |
| m05-type-driven | 0 | 6mo | No flags | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by actionbook
View all by actionbook →You might also like
organize-modules
r3bl-org
Apply private modules with public re-exports pattern for clean API design. Includes conditional visibility for docs and tests. Use when creating modules, organizing mod.rs files, or before creating commits.
m06-error-handling
actionbook
CRITICAL: Use for error handling. Triggers: Result, Option, Error, ?, unwrap, expect, panic, anyhow, thiserror, when to panic vs return Result, custom error, error propagation, 错误处理, Result 用法, 什么时候用 panic
m05-type-driven
actionbook
CRITICAL: Use for type-driven design. Triggers: type state, PhantomData, newtype, marker trait, builder pattern, make invalid states unrepresentable, compile-time validation, sealed trait, ZST, 类型状态, 新类型模式, 类型驱动设计
minimize-rust-ffi-crate-surface
RediSearch
Remove Rust-defined C symbols that are either unused or only used in C/C++ unit tests.
upgrade-oxc
rolldown
Upgrade oxc, run codegen, and fix any breaking changes.
clean-code
gregoire78
Apply clean code practices in this repository with small, safe refactors, explicit naming, reduced complexity, and behavior-preserving changes. Use for readability improvements, technical debt cleanup, and maintainability reviews in Rust code.