4.2Integer types

Last updated June 11, 2026

An integer is a whole number: no fractional part, possibly negative. Rust gives you ten integer types, and despite the apparent abundance, the system fits in one sentence: pick a size (8, 16, 32, 64, or 128 bits) and pick whether negatives are allowed (i for signed, u for unsigned).

The ranges follow from lesson 4.1's arithmetic: n bits make 2ⁿ patterns. An unsigned (u) type spends all its patterns on 0 upward, so u8 covers 0 through 255. A signed (i) type spends half its patterns on negatives, so i8 covers −128 through 127: same 256 patterns, different neighborhood. Need the exact bounds in code? Every type carries them as constants:

fn main() {
    println!("i32 spans {} to {}", i32::MIN, i32::MAX);
    println!("u16 spans {} to {}", u16::MIN, u16::MAX);
}

i32 spans -2147483648 to 2147483647
u16 spans 0 to 65535

Which one?

The honest answer is that one of them is the default and the rest are for reasons:

What about unsigned for values that "can't be negative," like an age or a count? Tempting, sometimes right, and worth a moment of caution: subtraction is where unsigned types bite. A count of 3 minus a count of 5 is −2, and −2 does not exist in u32's world; exactly what happens then is the next lesson's whole subject (4.4), but "nothing good by accident" is a fair preview. Prefer signed for quantities you'll do arithmetic on, and treat unsigned as a statement that negative values are impossible, not merely unexpected. (One unsigned type is unavoidable and everywhere, usize, and it gets the next lesson, 4.3.)

The classic disaster that doesn't compile here

If you ask a C++ veteran about unsigned types, you'll hear war stories, and the worst ones come from mixing: compare a signed and an unsigned value there, and the signed one is silently converted, so -1 < 1u evaluates to false (the −1 becomes 4,294,967,295 on the way in). Programs make absurd decisions, nothing crashes, and someone debugs it on a weekend.

Here's that bug, attempted in Rust:

fn main() {
    let signed: i32 = -1;
    let unsigned: u32 = 1;
    if signed < unsigned {
        println!("sanity prevails");
    }
}

error[E0308]: mismatched types
 --> src/main.rs:4:17
  |
4 |     if signed < unsigned {
  |        ------   ^^^^^^^^ expected `i32`, found `u32`
  |        |
  |        expected because this is `i32`

Rust has no implicit numeric conversions, none, not even the "safe-looking" ones. Different integer types don't compare, don't add, and don't pass for each other without an explicit conversion that you write and therefore think about (lesson 4.10). The entire silent-mixing genre of bug is not rare in Rust; it's unrepresentable.

Quiz time

Question #1

Without the table: what's the largest value of u16, and how do you derive it from the size?

Question #2

Pick a sensible type for each, with one phrase of why: (a) a person's age in years, (b) the byte count of a possibly-huge file, (c) a temperature change, which might be negative, (d) one byte read from a network packet.

Question #3

Predict the compiler's reaction:

fn main() {
    let total: i64 = 100;
    let count: i32 = 4;
    println!("{}", total + count);
}

Two integer types remain, the odd ones whose size depends on your machine, and they come bundled with the rest of the literal syntax.