--- title: "4.9 Type inference and annotations" description: "How Rust infers types from values and usage, the i32 and f64 defaults, and the rare cases where it needs your help." url: "https://learnrust.net/chapter-4/type-inference-and-annotations/" last_updated: "2026-06-11" --- # 4.9 Type inference and annotations 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: ```rust fn main() { let x = 5; let y: i64 = x; println!("{x} {y}"); } ``` This compiles, which should surprise you for a second. Lesson [4.2](https://learnrust.net/chapter-4/integer-types/) 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. > **Key insight** > > Inference changes *ergonomics*, never *rules*. The types are all still there, fixed at compile time, checked everywhere, exactly as this chapter taught; you've just delegated the typing of them. That's why Rust feels lighter than C++ (where the equivalent feature, `auto`, arrived late and gets used cautiously) while being stricter: omitting a type annotation costs no safety, because the compiler wasn't relying on your annotation anyway. It was always doing its own bookkeeping. ## 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](https://learnrust.net/chapter-1/developing-your-first-program/). 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: ```rust 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. > **Best practice** > > Let inference do its job for locals whose type is obvious from a glance (`let total = price * count;`). Add annotations when the compiler asks, when you want a non-default type (`let offset: i64 = 0;`), and at the occasional load-bearing moment where the next reader shouldn't have to deduce what a function-call chain produces. Function signatures, recall, are *always* explicit (lesson [2.3](https://learnrust.net/chapter-2/parameters-and-arguments/)); inference operates inside function bodies, between the explicit walls. That split (inferred interiors, declared boundaries) is much of why large Rust codebases stay readable. ## Quiz time **Question #1** Name the type of each variable, no compiler allowed: ```rust let a = 250; let b = 250.0; let c = 250u8; let d = false; let e = 'e'; ```
Show solution `a`: `i32` (integer fallback). `b`: `f64` (float fallback). `c`: `u8` (suffix). `d`: `bool`. `e`: `char`.
**Question #2** Now the trick version. What's the type of `a` here, and why? ```rust fn takes_u8(n: u8) { println!("{n}"); } fn main() { let a = 250; takes_u8(a); } ```
Show solution `u8`. The literal's type was decided by where `a` *went*: it's passed to a function demanding `u8`, the compiler works backward, and the `i32` fallback never enters the picture (fallbacks only apply when no evidence exists). Whole-body inference, exactly as in the lesson's `i64` example.
**Question #3** Without running it: does `let x = 300; takes_u8(x);` (same `takes_u8` as above) compile?
Show solution No, and the error is an old friend in a new hat: inference types `x` as `u8` (its usage demands it), at which point the literal `300` is out of range for `u8`, and the literal-out-of-range rejection from lesson [4.3](https://learnrust.net/chapter-4/isize-usize-and-integer-literals/) fires. Inference picked the type; the range rules then applied as usual. Ergonomics changed, rules didn't.
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. ## Sitemap See the full [sitemap](https://learnrust.net/sitemap.md) for all pages.