Agent Skills: Zero-Cost Abstraction

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, 泛型, 特征, 零成本抽象, 单态化

UncategorizedID: zhanghandong/rust-skills/m04-zero-cost

Install this agent skill to your local

pnpm dlx add-skill https://github.com/zhanghandong/rust-skills/tree/HEAD/skills/m04-zero-cost

Skill Files

Browse the full folder contents for m04-zero-cost.

Download Skill

Loading file tree…

skills/m04-zero-cost/SKILL.md

Skill Metadata

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, 泛型, 特征, 零成本抽象, 单态化"

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>) { }  // 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 |