Specialization

22 min read

Specialization is a long-promised Rust feature that would let a more specific trait implementation override a more general one — for example, a blanket impl<T> Trait for T that a dedicated impl Trait for String is allowed to refine. It is genuinely useful, partially implemented, and still not stable after a decade of design work. This page explains what it would buy you, exactly why it is stuck on nightly, and — most importantly — the safe, stable patterns that cover the vast majority of cases today.

Quick Overview

Today, Rust’s coherence rules forbid two trait implementations from overlapping: you cannot have both impl<T> Summary for T and impl Summary for String, because String matches both and the compiler refuses to guess which one you meant. Specialization would lift that restriction in a controlled way — the most specific applicable impl wins, and a base impl marks the methods that may be overridden with the default keyword.

For a TypeScript/JavaScript developer the closest mental model is function overloads (function f(x: string): ...; function f(x: number): ...) or a chain of typeof/instanceof checks: one logical operation with several behaviors chosen by the argument’s concrete type. The crucial difference is when the choice happens. TypeScript overloads are erased — at runtime there is a single function body that hand-dispatches on typeof. Rust’s specialization would resolve at compile time through monomorphization, producing separate, fully-optimized machine code per type with zero runtime dispatch. The catch: getting that resolution to be sound in the presence of lifetimes has resisted a complete solution, which is why the feature is still gated.

Note: Everything in the “Rust Equivalent,” “Best Practices,” and “Real-World Example” sections compiles on stable Rust 1.96.0 (2024 edition). The genuine specialization feature only appears in the “What Specialization Would Enable” subsection and the pitfalls, and is clearly marked as nightly-only.

TypeScript/JavaScript Example

TypeScript lets you give one function several overload signatures and write a single implementation that dispatches on the runtime type. This is the everyday tool a TS developer reaches for when one operation should behave differently for different concrete types:

1
// One name, several specialized signatures, one hand-written dispatcher.
2
function describe(value: string): string;
3
function describe(value: number): string;
4
function describe(value: unknown[]): string;
5
function describe(value: unknown): string {
6
  // The "specialization" is a manual runtime type test.
7
  if (typeof value === "string") {
8
    return `a string of length ${value.length}`;
9
  }
10
  if (typeof value === "number") {
11
    return `the number ${value} (even? ${value % 2 === 0})`;
12
  }
13
  if (Array.isArray(value)) {
14
    return `an array of ${value.length} items`;
15
  }
16
  return `some value: ${String(value)}`;
17
}
18

19
console.log(describe("hello"));
20
console.log(describe(42));
21
console.log(describe([1, 2, 3]));

Running it with Node v22 prints:

1
a string of length 5
2
the number 42 (even? true)
3
an array of 3 items

Two things matter here. First, the overload signatures are pure compile-time annotations — tsc erases them, and at runtime there is exactly one function whose body inspects value. Second, that inspection is the only dispatch mechanism JavaScript has: a runtime typeof/Array.isArray chain. There is no way to ask the engine “compile a separate, specialized version of this function for string.” Rust’s specialization aims to provide exactly that — but at compile time, and that is precisely what makes it hard.

Rust Equivalent

On stable Rust you cannot write overlapping impls, so the idiomatic equivalent of the overloaded describe is a trait with a default method that specific types override. The blanket behavior lives in the trait’s default body; any type that wants something more specific provides its own impl. Because the consumer is generic, dispatch is resolved at compile time with zero runtime cost:

1
use std::fmt::Debug;
2

3
// A metrics sink. Every metric type gets a sensible *default* encoding; types
4
// that care can override it with a compact, allocation-light one. This is the
5
// trait-default-override pattern -- the stable workhorse approximation of
6
// specialization.
7
trait Metric: Debug {
8
    // Default: a verbose, Debug-based line that works for any metric type.
9
    fn encode(&self) -> String {
10
        format!("{self:?}")
11
    }
12
}
13

14
#[derive(Debug)]
15
struct Counter {
16
    name: &'static str,
17
    value: u64,
18
}
19

20
#[derive(Debug)]
21
struct Gauge {
22
    name: &'static str,
23
    value: f64,
24
}
25

26
// Counter provides a *more specific* implementation, overriding the default.
27
impl Metric for Counter {
28
    fn encode(&self) -> String {
29
        format!("{}_total {}", self.name, self.value)
30
    }
31
}
32

33
// Gauge does NOT override encode(): it falls back to the Debug-based default.
34
impl Metric for Gauge {}
35

36
// Generic consumer: monomorphized, so each call dispatches statically at compile
37
// time with zero runtime cost -- exactly what real specialization promises.
38
fn emit<M: Metric>(m: &M) {
39
    println!("{}", m.encode());
40
}
41

42
fn main() {
43
    emit(&Counter { name: "requests", value: 99 });
44
    emit(&Gauge { name: "cpu", value: 0.7 });
45
}

Output:

1
requests_total 99
2
Gauge { name: "cpu", value: 0.7 }

Counter uses its specialized encode; Gauge silently inherits the generic default. This is not the same as true specialization — you cannot have a blanket impl<T> Metric for T and override it for Counter — but for the common “general behavior plus per-type refinements” shape, it is the correct, stable answer.

Detailed Explanation

Let us connect the TypeScript and Rust versions line by line, then explain why the obvious translation does not compile.

What the TypeScript does. describe’s three overload signatures tell tsc which argument types are legal and what each returns. The single implementation body is the only thing that exists at runtime, and it dispatches with typeof/Array.isArray. The “specialization” is therefore a runtime branch — JavaScript has no concept of compiling a separate describe_for_string.

What the stable Rust does. The Metric trait declares encode with a default body. impl Metric for Counter { fn encode ... } overrides that body; impl Metric for Gauge {} accepts it. When you call emit(&counter), the compiler monomorphizes emit into a version specialized to Counter and statically resolves m.encode() to Counter::encode. There is no runtime type tag, no branch — the right code is baked in at compile time. (Monomorphization and static dispatch are covered in Generic Functions and Default implementations.)

Why the “natural” translation fails. The instinct is to write a blanket impl and then refine it:

1
use std::fmt::Display;
2

3
trait Summary {
4
    fn summarize(&self) -> String;
5
}
6

7
// A blanket impl for everything that is Display.
8
impl<T: Display> Summary for T {
9
    fn summarize(&self) -> String {
10
        format!("{self}")
11
    }
12
}
13

14
// A "more specific" impl for String -- but String IS Display, so they overlap.
15
// does not compile (error[E0119]: conflicting implementations)
16
impl Summary for String {
17
    fn summarize(&self) -> String {
18
        format!("string: {self}")
19
    }
20
}
21

22
fn main() {}

The compiler rejects this with the real error:

1
error[E0119]: conflicting implementations of trait `Summary` for type `String`
2
  --> src/main.rs:15:1
3
   |
4
 8 | impl<T: Display> Summary for T {
5
   | ------------------------------ first implementation here
6
...
7
15 | impl Summary for String {
8
   | ^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `String`
9

10
For more information about this error, try `rustc --explain E0119`.

This is the entire problem in one message. String satisfies both impls, so the compiler has two candidate summarize methods and no rule to pick between them. Coherence demands that at most one impl applies to any given type, so it refuses the program. Specialization is the feature that would teach the compiler the missing rule: “when two impls overlap, prefer the more specific one.”

What specialization would enable (nightly only)

On a nightly compiler you can turn the feature on and write exactly the overlapping impls that stable forbids. The base impl marks overridable methods with default, and the specific impl wins:

1
// requires nightly: #![feature(specialization)] is rejected on stable.
2
#![feature(specialization)]
3
#![allow(incomplete_features)]
4

5
trait Summary {
6
    fn summarize(&self) -> String;
7
}
8

9
// Blanket impl. `default` says "a more specific impl may override this".
10
impl<T: std::fmt::Debug> Summary for T {
11
    default fn summarize(&self) -> String {
12
        format!("generic: {self:?}")
13
    }
14
}
15

16
// The more specific impl for String "wins" over the blanket one.
17
impl Summary for String {
18
    fn summarize(&self) -> String {
19
        format!("a string of length {}", self.len())
20
    }
21
}
22

23
fn main() {
24
    println!("{}", 42i32.summarize());
25
    println!("{}", vec![1, 2].summarize());
26
    println!("{}", String::from("hello").summarize());
27
}

Compiled with rustc 1.98.0-nightly (using rustup run nightly rustc spec.rs), this builds and runs:

1
generic: 42
2
generic: [1, 2]
3
a string of length 5

The i32 and Vec fall through to the blanket impl; String uses its specialized one — all resolved statically, with no runtime type check. That is the prize. The reason you cannot rely on it is in the next section.

Warning: The full specialization feature is flagged incomplete_features for a reason — it can accept unsound programs and has been known to ICE (internal compiler error). Do not build production code on it. The narrower min_specialization gate is safer but still nightly-only and still incomplete.

Key Differences

Aspect	TypeScript overloads / `typeof` dispatch	Rust specialization (hypothetical, nightly)	Stable Rust today
When dispatch happens	Runtime (`typeof`, `instanceof`)	Compile time (monomorphization)	Compile time (generics + default methods)
Overlapping definitions allowed?	Yes — overloads are erased to one body	Yes — most specific impl wins	No — coherence forbids overlap (E0119)
Cost	A runtime branch per call	Zero — separate compiled code per type	Zero — separate compiled code per type
Stability	Stable TS feature	Unstable, gated behind nightly flags	Fully stable
Soundness concern	None (dynamically typed anyway)	Lifetime-dependent specialization can be unsound	N/A — the patterns are sound by construction

The headline conceptual difference from TypeScript: in TS, “which version runs” is a value-level question answered at runtime, so it can never be unsound — every path is just JavaScript. In Rust, “which impl applies” is a type-level question the compiler must answer while still guaranteeing memory safety. The hard part is that Rust erases lifetimes before generating code, yet specialization wants to choose impls partly based on type identity. If an impl could be selected based on a lifetime — say a special case for &'static T versus &'a T — the choice would depend on information that no longer exists at codegen time. That mismatch is the root of the unsoundness, and resolving it cleanly is what has kept the feature off stable for years.

Common Pitfalls

Pitfall 1: Assuming the `specialization` feature is stable or “almost ready”

It is neither. Turning it on requires a nightly toolchain, and even there the compiler shouts that it is unsafe to rely on:

1
// does not compile on stable (error[E0554])
2
#![feature(specialization)]
3
// ... trait + impls ...
4
fn main() {}

On stable rustc 1.96.0, cargo run produces:

1
error[E0554]: `#![feature]` may not be used on the stable release channel
2
 --> src/main.rs:1:1
3
  |
4
1 | #![feature(specialization)]
5
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^
6

7
warning: the feature `specialization` is incomplete and may not be safe to use and/or cause compiler crashes
8
 --> src/main.rs:1:12
9
  |
10
1 | #![feature(specialization)]
11
  |            ^^^^^^^^^^^^^^
12
  |
13
  = note: see issue #31844 <https://github.com/rust-lang/rust/issues/31844> for more information
14
  = help: consider using `min_specialization` instead, which is more stable and complete
15
  = note: `#[warn(incomplete_features)]` on by default

Tracking issue #31844 has been open since 2016. Treat specialization as a research feature, not a roadmap item you can schedule against.

Pitfall 2: Writing overlapping impls on stable and expecting “most specific wins”

This is the E0119 error shown earlier. Newcomers from C++ (where partial template specialization exists) or from dynamic languages (where you just branch at runtime) often write a blanket impl plus a refinement and are surprised it is rejected. The fix is one of the stable patterns in Best Practices — there is no flag you can flip on stable to make overlap legal.

Pitfall 3: Forgetting `default` even on nightly with `min_specialization`

min_specialization is the conservative subset the Rust team hopes to stabilize first. It still requires the base impl to mark a method default before any specific impl may override it. Omitting it is an error, even on nightly:

1
// requires nightly AND still fails: base method must be `default`
2
#![feature(min_specialization)]
3

4
trait Fast {
5
    fn run(&self) -> &'static str;
6
}
7

8
impl<T> Fast for T {
9
    // No `default` here -- so this method is final and cannot be specialized.
10
    fn run(&self) -> &'static str {
11
        "generic"
12
    }
13
}
14

15
impl Fast for u8 {
16
    fn run(&self) -> &'static str {
17
        "u8"
18
    }
19
}
20

21
fn main() {}

rustup run nightly rustc reports:

1
error[E0520]: `run` specializes an item from a parent `impl`, but that item is not marked `default`
2
  --> nodefault.rs:15:5
3
   |
4
 7 | impl<T> Fast for T {
5
   | ------------------ parent `impl` is here
6
...
7
15 |     fn run(&self) -> &'static str {
8
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot specialize default item `run`
9
   |
10
   = note: to specialize, `run` in the parent `impl` must be marked `default`
11

12
error: aborting due to 1 previous error

Adding default fn run to the blanket impl makes both versions of the program (specialization and min_specialization) compile and run, printing generic then u8.

Pitfall 4: Reaching for the autoref trick when a simpler tool exists

There is a clever stable technique (next section) that approximates compile-time specialization using method-resolution priority. It works, but it is subtle, fragile under refactoring, and confusing to readers who do not know it. Use it only when you truly need compile-time selection between “implements trait X” and “implements trait Y,” and document it. For most code, a default method, an enum, or explicit methods are clearer.

Best Practices

When you feel the pull toward specialization, pick the simplest stable pattern that fits the shape of your problem. In rough order of preference:

This is the pattern in the Rust Equivalent above: put the general behavior in a trait’s default method and let specific types override it. It covers the vast majority of “I want a fallback plus special cases” needs and is completely idiomatic. See Default implementations.

2. An enum, when the set of types is closed

If you know all the types up front, do not abstract over them at all — enumerate them. An enum plus an exhaustive match is faster, clearer, and impossible to get wrong than any specialization scheme:

1
// When the set of "specialized" cases is closed, an enum + match beats any
2
// specialization machinery: one type, exhaustive dispatch, no overlap problem.
3
enum Value {
4
    Text(String),
5
    Int(i64),
6
    List(Vec<i64>),
7
}
8

9
impl Value {
10
    fn render(&self) -> String {
11
        match self {
12
            Value::Text(s) => format!("text({}): {s:?}", s.len()),
13
            Value::Int(n) => format!("int: {n} (even? {})", n % 2 == 0),
14
            Value::List(xs) => format!("list of {}", xs.len()),
15
        }
16
    }
17
}
18

19
fn main() {
20
    for v in [
21
        Value::Text("hi".into()),
22
        Value::Int(42),
23
        Value::List(vec![1, 2, 3]),
24
    ] {
25
        println!("{}", v.render());
26
    }
27
}

Output:

1
text(2): "hi"
2
int: 42 (even? true)
3
list of 3

3. Runtime dispatch with `Any` / downcasting, when the special case is rare

If you have a truly generic fn f<T: ...>(x: &T) and want a fast path for one or two concrete types, you can ask at runtime via std::any::Any. This trades a tiny runtime check for not needing nightly:

1
use std::any::Any;
2
use std::fmt::Debug;
3

4
// A generic function that does something *special* for String / i32 and the
5
// generic thing otherwise. The "specialization" is a runtime type check.
6
fn describe<T: Debug + Any>(value: &T) -> String {
7
    let any = value as &dyn Any;
8
    if let Some(s) = any.downcast_ref::<String>() {
9
        format!("a string of length {}: {s:?}", s.len())
10
    } else if let Some(n) = any.downcast_ref::<i32>() {
11
        format!("the integer {n} (even? {})", n % 2 == 0)
12
    } else {
13
        format!("some value: {value:?}")
14
    }
15
}
16

17
fn main() {
18
    println!("{}", describe(&String::from("hi")));
19
    println!("{}", describe(&42i32));
20
    println!("{}", describe(&vec![1, 2, 3]));
21
}

Output:

1
a string of length 2: "hi"
2
the integer 42 (even? true)
3
some value: [1, 2, 3]

Tip: Any only works for 'static types (no borrowed lifetimes), and the check is a runtime comparison, so do not put it on a hot inner loop where you expected zero-cost dispatch. Use it for occasional fast paths, not pervasive ones.

4. The autoref (method-resolution) trick, for compile-time selection on trait bounds

When you genuinely need the compiler to choose at compile time between “T implements Display” and “T only implements Debug,” you can exploit how method resolution prefers fewer autorefs. Two traits share a method name; one is implemented on T (fewer autorefs, tried first), the other on &T. The compiler reaches the &T impl only when the T impl does not apply:

1
use std::fmt::{Debug, Display};
2

3
// More specific: requires Display. Implemented on `T`, so it is tried first.
4
trait ViaDisplay {
5
    fn render(&self) -> String;
6
}
7
impl<T: Display> ViaDisplay for T {
8
    fn render(&self) -> String {
9
        format!("via Display: {self}")
10
    }
11
}
12

13
// Less specific: works for any Debug, but implemented on `&T`. Because it needs
14
// one extra autoref, the compiler only reaches it when the Display impl above
15
// does not apply.
16
trait ViaDebug {
17
    fn render(&self) -> String;
18
}
19
impl<T: Debug> ViaDebug for &T {
20
    fn render(&self) -> String {
21
        format!("via Debug: {self:?}")
22
    }
23
}
24

25
#[derive(Debug)]
26
struct Point {
27
    x: i32,
28
    y: i32,
29
}
30

31
fn main() {
32
    // i32 implements Display -> the Display impl wins.
33
    let n = 7;
34
    println!("{}", (&n).render());
35

36
    // Point implements only Debug -> autoref reaches the &T impl.
37
    let p = Point { x: 1, y: 2 };
38
    println!("{}", (&p).render());
39
}

Output:

1
via Display: 7
2
via Debug: Point { x: 1, y: 2 }

This compiles cleanly on stable; the (&value).render() call site forces method resolution to consider the autoref ladder. It is the technique behind crates like anyhow (selecting an error-conversion strategy) and the well-known “autoref specialization” blog posts. Reserve it for library code where the ergonomics justify the cleverness, and comment it heavily.

Note: Several real std methods already contain internal specialization (compiled with nightly inside the standard library) — for example, Vec::extend and From<&[T]> use a hidden SpecExtend/SpecFrom trait to pick a memcpy fast path for Copy elements. You benefit from this every day; you just cannot write it yourself on stable. This is also why “specialization is unstable” coexists with “specialization ships in your binary.”

Real-World Example

A common production need: a serializer that wants a zero-extra-allocation fast path for string slices and a general path for anything Display. With true specialization you would write one generic method and let a &str impl override it. On stable, the honest, zero-magic version exposes two explicit methods and lets the call site pick — clearer than the autoref trick and just as fast, because both are statically dispatched:

1
use std::fmt::Display;
2

3
// A tiny JSON-string encoder. We want a fast path for `&str` (push the bytes
4
// directly, no temporary allocation) and a general path for anything Display.
5
// Stable Rust cannot overlap impls, so we offer two methods; each is resolved
6
// statically, so there is no runtime dispatch cost.
7
struct Encoder {
8
    out: String,
9
}
10

11
impl Encoder {
12
    fn new() -> Self {
13
        Encoder { out: String::new() }
14
    }
15

16
    // General path: any Display value, rendered into a temporary then quoted.
17
    fn write_display<T: Display>(&mut self, value: &T) {
18
        self.out.push('"');
19
        self.out.push_str(&value.to_string()); // allocates a temporary String
20
        self.out.push('"');
21
    }
22

23
    // Specialized fast path: a &str needs no intermediate String at all.
24
    fn write_str(&mut self, value: &str) {
25
        self.out.push('"');
26
        self.out.push_str(value); // borrow directly, zero extra allocation
27
        self.out.push('"');
28
    }
29
}
30

31
fn main() {
32
    let mut enc = Encoder::new();
33
    enc.write_str("hello"); // fast path: no temporary String
34
    enc.write_display(&42); // general path
35
    enc.write_display(&3.5f64); // general path
36
    println!("{}", enc.out);
37
}

Output:

1
"hello""42""3.5"

If, later, the set of supported value kinds becomes closed and known, you would refactor Encoder to accept an enum Value and match on it (Best Practice #2) — eliminating even the possibility of calling the wrong method. The lesson generalizes: most desires for specialization are really desires for one of “a default plus overrides,” “an enum,” “an occasional runtime check,” or “compile-time trait selection,” and stable Rust has a clean, sound tool for each. The actual specialization feature remains a research project — worth understanding so you can read nightly-only library internals, but not something to design around.

Exercises

Exercise 1: Default-method “specialization”

Difficulty: Beginner

Objective: Replace a would-be specialization with the stable trait-default-override pattern.

Instructions: Define a trait Notify with a default method message(&self) -> String returning "You have a notification". Implement Notify for a struct Email { subject: String } so it overrides the default with format!("New email: {}", self.subject), and for a struct Heartbeat; that accepts the default. Write a generic fn send<N: Notify>(n: &N) that prints n.message(), and call it with both types.

Solution

1
trait Notify {
2
    fn message(&self) -> String {
3
        String::from("You have a notification")
4
    }
5
}
6

7
struct Email {
8
    subject: String,
9
}
10

11
struct Heartbeat;
12

13
impl Notify for Email {
14
    fn message(&self) -> String {
15
        format!("New email: {}", self.subject)
16
    }
17
}
18

19
// Heartbeat takes the default message.
20
impl Notify for Heartbeat {}
21

22
fn send<N: Notify>(n: &N) {
23
    println!("{}", n.message());
24
}
25

26
fn main() {
27
    send(&Email { subject: "Invoice".into() });
28
    send(&Heartbeat);
29
}

Output:

1
New email: Invoice
2
You have a notification

Exercise 2: Runtime fast path with `Any`

Difficulty: Intermediate

Objective: Use std::any::Any to give one concrete type a special path inside an otherwise-generic function.

Instructions: Write fn byte_len<T: std::any::Any>(value: &T) -> Option<usize> that returns Some(n) with the byte length when value is a String or a &'static str, and None for everything else. (Hint: downcast to String and to &'static str separately.) Test it with a String, a &'static str, and an i32.

Solution

1
use std::any::Any;
2

3
fn byte_len<T: Any>(value: &T) -> Option<usize> {
4
    let any = value as &dyn Any;
5
    if let Some(s) = any.downcast_ref::<String>() {
6
        Some(s.len())
7
    } else if let Some(s) = any.downcast_ref::<&'static str>() {
8
        Some(s.len())
9
    } else {
10
        None
11
    }
12
}
13

14
fn main() {
15
    println!("{:?}", byte_len(&String::from("hello"))); // Some(5)
16
    println!("{:?}", byte_len(&"hi")); // Some(2)
17
    println!("{:?}", byte_len(&42i32)); // None
18
}

Output:

1
Some(5)
2
Some(2)
3
None

Note that Any requires 'static, which is why we match &'static str specifically; a borrowed &'a str with a non-'static lifetime is not Any.

Exercise 3: Autoref specialization

Difficulty: Advanced

Objective: Use the stable autoref method-resolution trick to pick, at compile time, between a “clone via Clone” path and a “describe via Debug” fallback.

Instructions: Define a wrapper struct Wrap<T>(T). Give it an inherent method act(&self) -> String on impl<T: Clone> Wrap<T> returning "cloned", and a trait method of the same name on impl<T: Debug> DebugFallback for Wrap<T> returning format!("debug: {:?}", self.0). Because inherent methods are resolved before trait methods, the Clone path wins whenever T: Clone, and the trait fallback is reached otherwise. Verify that Wrap(vec![1, 2, 3]) (whose T is Clone) takes the "cloned" path, while a type that is Debug but not Clone takes the fallback.

Solution

1
use std::fmt::Debug;
2

3
// We want: if T: Clone, say "cloned"; otherwise (T: Debug) say "debug: ...".
4
// Wrap the value so we control the method-resolution ladder precisely.
5
struct Wrap<T>(T);
6

7
// More specific: an *inherent* method on Wrap<T> when T: Clone. Inherent methods
8
// are tried before trait methods, so this wins whenever T: Clone.
9
impl<T: Clone> Wrap<T> {
10
    fn act(&self) -> String {
11
        String::from("cloned")
12
    }
13
}
14

15
// Fallback: a trait method, reached only when the inherent method above does not
16
// apply (i.e. T is not Clone).
17
trait DebugFallback {
18
    fn act(&self) -> String;
19
}
20
impl<T: Debug> DebugFallback for Wrap<T> {
21
    fn act(&self) -> String {
22
        format!("debug: {:?}", self.0)
23
    }
24
}
25

26
// NotClone derives only Debug, so it is NOT Clone.
27
#[derive(Debug)]
28
struct NotClone {
29
    id: u32,
30
}
31

32
fn main() {
33
    let v = Wrap(vec![1, 2, 3]); // T = Vec<i32>: Clone -> inherent method wins
34
    println!("{}", v.act());
35

36
    let nc = Wrap(NotClone { id: 7 }); // T: Debug, not Clone -> trait fallback
37
    println!("{}", nc.act());
38
}

Output:

1
cloned
2
debug: NotClone { id: 7 }

Vec<i32> is Clone, so the inherent act applies and — because inherent methods outrank trait methods in resolution — it wins. NotClone is not Clone, so the inherent method does not apply and the compiler falls through to the DebugFallback trait method. Choosing an inherent method over a trait method by their bounds is the robust form of the autoref trick; anyhow uses a closely related construction to select an error-conversion strategy at compile time, entirely on stable Rust.

Specialization

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

What specialization would enable (nightly only)

Key Differences

Common Pitfalls

Pitfall 1: Assuming the specialization feature is stable or “almost ready”

Pitfall 2: Writing overlapping impls on stable and expecting “most specific wins”

Pitfall 3: Forgetting default even on nightly with min_specialization

Pitfall 4: Reaching for the autoref trick when a simpler tool exists

Best Practices

1. Trait with default methods (general behavior + refinements)

2. An enum, when the set of types is closed

3. Runtime dispatch with Any / downcasting, when the special case is rare

4. The autoref (method-resolution) trick, for compile-time selection on trait bounds

Real-World Example

Further Reading

Exercises

Exercise 1: Default-method “specialization”

Exercise 2: Runtime fast path with Any

Exercise 3: Autoref specialization

Pitfall 1: Assuming the `specialization` feature is stable or “almost ready”

Pitfall 3: Forgetting `default` even on nightly with `min_specialization`

3. Runtime dispatch with `Any` / downcasting, when the special case is rare

Exercise 2: Runtime fast path with `Any`