Agent Skills
› NeverSight/learn-skills.dev
› m04-zero-cost
m04-zero-cost
GitHub指导Rust泛型与特征设计，通过零成本抽象原则权衡静态/动态分发。针对E0277等错误提供决策路径，结合单态化、dyn trait及类型驱动开发，优化性能与代码结构。
Trigger Scenarios
E0277
E0308
E0599
generic
trait
impl
dyn
where
monomorphization
static dispatch
dynamic dispatch
impl Trait
trait bound not satisfied
泛型
特征
零成本抽象
单态化
Install
npx skills add NeverSight/learn-skills.dev --skill m04-zero-cost -g -y
SKILL.md
Frontmatter
{
"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:
-
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 |
Version History
- e0220ca Current 2026-07-05 23:02
