4.9Type inference and annotations

Last updated June 11, 2026

You've now met enough types for a confession: most Rust code names almost none of them. This entire chapter has carefully annotated its variables, the way a driving instructor narrates every mirror check; real code mostly writes let count = 0; and trusts the machinery. This lesson is about that machinery, type inference, which has been working on your behalf since lesson 1.3 and deserves five minutes of daylight.

How far inference reaches

The simple version you already know: the compiler deduces a variable's type from its initializer. let x = 5.0; makes an f64, no annotation needed. But Rust's inference is smarter than one-line-at-a-time, and one example shows its actual reach:

fn main() {
    let x = 5;
    let y: i64 = x;
    println!("{x} {y}");
}

This compiles, which should surprise you for a second. Lesson 4.2 drilled in that there are no implicit conversions, and an i32 can't initialize an i64... but check the assumption: who said x is an i32? Not us, and not line 2 by itself. The compiler reads the whole function before deciding, sees x flow into an i64 on line 3, and concludes x was an i64 all along. No conversion happened; the literal 5 was given the type its future demanded.

That's the real model: an unannotated integer literal is typeless potential until the surrounding code pins it down, and i32 is merely the fallback when nothing does (f64 likewise for float literals). Inference gathers evidence from everywhere a value travels: initializers, function arguments it's passed to, return types it ends up in.

Where inference needs help

Sometimes the evidence really is insufficient, and there's one place you've already lived this: the number-reading recipe from lesson 1.12. Here's its mystery, finally dissolved. parse can produce many types (it'll happily target i32, u8, f64...), so something must say which. Delete the annotation and watch the honest failure:

fn main() {
    let guess = "42".parse().expect("not a number");
    println!("{guess}");
}

error[E0284]: type annotations needed
 --> src/main.rs:2:9
  |
2 |     let guess = "42".parse().expect("not a number");
  |         ^^^^^        ----- type must be known at this point
  |
help: consider giving `guess` an explicit type
  |
2 |     let guess: /* Type */ = "42".parse().expect("not a number");
  |              ++++++++++++

The compiler isn't being dense; "42" could legitimately become half a dozen types, and guessing would be worse than asking. The : i32 in the recipe was never decoration. It was the answer to this question, supplied in advance.

(There's a second way to answer: tell parse directly, with a syntax the community has nicknamed the turbofish for its silhouette. It appears in lesson 5.6, where the recipe gets its full teardown; the name alone is your preview.)

When to annotate anyway

Beyond the compiler's demands, annotations have one more constituency: readers.

Quiz time

Question #1

Name the type of each variable, no compiler allowed:

let a = 250;
let b = 250.0;
let c = 250u8;
let d = false;
let e = 'e';

Question #2

Now the trick version. What's the type of a here, and why?

fn takes_u8(n: u8) {
    println!("{n}");
}

fn main() {
    let a = 250;
    takes_u8(a);
}

Question #3

Without running it: does let x = 300; takes_u8(x); (same takes_u8 as above) compile?

One question remains from all this strictness: when you legitimately need an i32 to become an i64, what do you actually write? Next lesson: conversions, done Rust's way.