m04-zero-cost
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, 泛型, 特征, 零成本抽象, 单态化
Install
npx skills add https://github.com/moeru-ai/auv/tree/main/.agents/skills/m04-zero-cost
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install moeru-ai-auv@llmmart
git clone https://github.com/moeru-ai/auv.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole moeru-ai/auv collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
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 |
Files (auv)
-
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 |
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.