From rust-skills
Guides decisions between compile-time (generics) and runtime (trait objects) polymorphism in Rust, with error-driven prompts for E0277, E0308, E0599.
How this skill is triggered — by the user, by Claude, or both
Slash command
/rust-skills:m04-zero-costThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> **Layer 1: Language Mechanics**
Layer 1: Language Mechanics
Do we need compile-time or runtime polymorphism?
Before choosing between generics and trait objects:
| 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? |
Before adding trait bounds:
What abstraction is needed?
When is type known?
What's the trade-off priority?
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? |
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>
| 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 |
// 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 | 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 |
| 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 |
A trait is object-safe if it:
Self: Sized boundSelfwhere Self: Sized for non-object-safe methods| 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 |
| When | See |
|---|---|
| Type-driven design | m05-type-driven |
| Domain abstraction | m09-domain |
| Performance concerns | m10-performance |
| Send/Sync bounds | m07-concurrency |
npx claudepluginhub actionbook/rust-skills --plugin rust-skillsEnforces idiomatic Rust patterns for ownership/borrowing, error handling with thiserror/anyhow, traits/generics, concurrency via Arc/Mutex/channels, and module design. Use when writing, reviewing, or refactoring Rust code.
Guides Rust best practices, common patterns, and idiomatic code including borrowing, error propagation, iterators, and design patterns like builder and newtype.
Enforces idiomatic Rust patterns for ownership, error handling, enums, traits, concurrency, and crate structure.