/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, 泛型, 特征, 零成本抽象, 单态化
$ npx -y skills add zhanghandong/rust-skills --skill m04-zero-cost --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/m04-zero-cost
Context preview
The summary Claude sees to decide when to auto-load this skill.
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, 泛型, 特征, 零成本抽象, 单态化
SKILL.md
m04-zero-cost.SKILL.mdname: 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
// 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: 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 |
Read more
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
// 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: 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 |
AI-powered Rust development assistant with meta-cognition framework
Other skills on rust-skills.
- /coding-guidelines
Use when asking about Rust code style or best practices. Keywords: naming, formatting, comment, clippy, rustfmt, lint, code style, best practice, P.NAM, G.FMT, code review, naming convention, variable naming, function naming, type naming, 命名规范, 代码风格, 格式化, 最佳实践, 代码审查, 怎么命名
Open skill - /core-actionbook
Internal support skill for actionbook MCP selectors used by Rust documentation research workflows. Use only when another rust-skills workflow explicitly requests actionbook-backed selectors.
Open skill - /core-agent-browser
Internal support skill for agent-browser CLI workflows used by rust-learner, docs-researcher, and crate-researcher. Use only when browser automation is explicitly required.
Open skill - /core-dynamic-skills
Internal command support for dynamic Rust crate skill management. Use only when explicitly invoked by /sync-crate-skills, /clean-crate-skills, or /update-crate-skill.
Open skill - /core-fix-skill-docs
Internal maintenance support for checking and fixing generated Rust skill documentation references. Use only when explicitly invoked by /fix-skill-docs.
Open skill - /domain-cli
Use when building CLI tools. Keywords: CLI, command line, terminal, clap, structopt, argument parsing, subcommand, interactive, TUI, ratatui, crossterm, indicatif, progress bar, colored output, shell completion, config file, environment variable, 命令行, 终端应用, 参数解析
Open skill

