Primitive Types and Overflow

Rust integers are explicitly sized and there is no implicit widening — the type is part of the value:

Literals carry no type until inference assigns one, and every base is available:

let dec = 982;
let hex = 0xFF;
let oct = 0o77;
let bin = 0b1010_1010;
let byte = b'A';        // u8, ONLY valid for ASCII in byte literals
let big = 1_000_000;    // underscores are digit separators

Conversions never happen implicitly. let sum: i64 = x + y; with x: i32 is error[E0308]: mismatched types, and the fix is an explicit as cast or the checked constructors:

let x: i32 = 1000;
let y = x as i64;                        // widening — safe
let t = 300_i32 as u8;                   // TRUNCATES to 44 — silent in release
let g = (-1_i32) as u32;                 // 4294967295 — two's complement reinterpretation

That truncation is legal Rust and a classic bug source: as is a reinterpretation of the low bits, not a range check. The safe API is i32::try_from(big).expect("fits") which returns Result (TryFromIntError), or .unwrap_or(u32::MAX) for saturating semantics. Rule of thumb used in review: casts in parsing/serialization boundaries are fine; casts buried in arithmetic get questioned.

Floats are f32 (single) and f64 (double, the default — let x = 3.14; is f64). Three float facts interviewers probe: integer division / between two floats still needs both sides float; 0.0 / 0.0 is NaN and NaN != NaN is true, so equality checks must use is_nan(); and floats are not Eq, so f64 keys in hash maps behave surprisingly. usize deserves one more warning: because it differs per target, code that assumes 64-bit usize breaks on 32-bit/WASM targets — do not store file offsets or money in it.

Two literal traps surface early. First, an out-of-range literal is rejected at compile time regardless of inference:

let x: u8 = 300;        // error: literal out of range `300`
let y: i8 = -128;       // fine — but 128_i8 is not, even before any arithmetic

Second, the default only applies when nothing else constrains the type — the moment a later line demands u16, the literal becomes u16:

let n = 5;              // unconstrained → i32
let m: u16 = n;         // error[E0308]: expected u16, found i32

Unsigned arithmetic has its own cliff, because subtraction below zero is overflow too:

let used = 10u8;
let free = used - 20;   // debug: attempt to subtract with overflow
                        // release: 246

This is how a capacity check turns into a huge number in production — the guard used >= 20 must come before the subtraction, not after.

Floats need one concrete number to stay honest. 0.1 + 0.2 == 0.3 is false; the sum is 0.30000000000000004, because 0.1 and 0.2 are not representable in binary floating point. Compare with a tolerance ((a - b).abs() < 1e-9) and never use a float as a hash-map key unless you round to a quantized step first. Also remember f64 is the default float type — let x = 3.14; is f64, and writing 3.14f32 is how you ask for single precision, halving storage at roughly 7 significant digits instead of 15–17.

char is a Unicode scalar value: any code point from 0 to 0x10FFFF excluding the surrogate range D800–DFFF. It is always four bytes in memory, unlike C's one-byte char:

let c = 'z';
let heart = '\u{2764}';    // escaped code point
let z: char = 'z';
let n = 42;
let bad = 'z' == n;         // error: char vs integer are distinct types
println!("{} is {} bytes", c, std::mem::size_of::<char>());  // 4

The four-byte size is the footprint of the type, not of encoded text: UTF-8 strings store 1–4 bytes per character depending on the code point, and only char normalizes to a fixed slot. This split creates the question every Rust text-processing code must answer — are you working in characters or bytes?

let s = "héllo";
assert_eq!(s.len(), 6);              // BYTES: é is 2 bytes in UTF-8
assert_eq!(s.chars().count(), 5);    // characters
for b in s.bytes() { /* u8 iterator */ }
for c in s.chars() { /* char iterator */ }

b'A' and 'A' look alike and mean different things: the first is a u8, the second a char. A byte literal is legal only for ASCII code points; anything non-ASCII must be written as a char escape. Slicing a string by byte index can split a multi-byte character and panic — you will see this concretely in Slices as Fat References.

Tuples group a fixed, heterogeneous sequence under one value:

let pair: (i32, f64) = (42, 3.14);
let (num, pi) = pair;          // destructuring — the idiomatic way to consume
let num = pair.0;              // field access also exists

fn center() -> (f64, f64) { (0.5, 0.5) }   // returning several values is a core use
let (x, y) = center();

Each element has its own type; the whole tuple has one size (sum of aligned elements). Tuples up to 12 elements have trait implementations (Debug, PartialOrd, …) — beyond that you need a struct. The empty tuple () is the unit type: exactly one value, also written (), with zero size — it is what functions return when they "return nothing" (fn log() {} really returns ()), and println! expands to code returning (). Option<()> and map keys of type () are rare but legal, and seeing -> () in generated code should not surprise you. Structs and enums wrap these primitives into named shapes next; the tuple is the anonymous, minimal version of the same idea.

char comes with a small standard toolkit that makes the four-byte cost worth paying:

let c = 'é';
assert!(c.is_alphabetic());
assert_eq!(c.to_ascii_uppercase(), 'É');   // no-op outside ASCII
assert_eq!(c as u32, 0xE9);                // code point as number

assert_eq!(char::from_u32(0x1F600), Some('\u{1F600}'));   // 😀
assert_eq!(char::from_u32(0xD800), None);                 // surrogate: not a scalar

That None is the definition made executable: a char can never hold a UTF-16 surrogate, so text produced through char is always valid Unicode. Going the other way — bytes to text — is std::str::from_utf8(&[u8]), which returns Result and rejects invalid sequences instead of producing mojibake.

One more layer exists above the scalar, and interviews about text almost always reach for it: grapheme clusters. The word "é" can be encoded as U+00E9 (one scalar) or as e plus U+0301 (two scalars). Both render identically, so "café".chars().count() is 4 or 5 depending on how the file was written, while a user perceives 4 characters. The unicode-segmentation crate counts what a human sees: s.graphemes(true).count(). The rule to carry: len() is bytes, chars() is scalars, graphemes() is user-perceived characters — pick the unit your operation actually means.

Tuples finish with a sizing detail: std::mem::size_of::<(i32, f64, u8)>() reports 16, not 13, because the layout pads to each element's alignment. When a size matters, the struct with #[repr(C)] is the tool that makes padding explicit and stable.

Integer overflow is where primitive types stop being trivia. Rust's rule: arithmetic overflow panics in debug builds and wraps in release builds, unless you ask for explicit behavior.

fn main() {
    let mut v: u8 = 250;
    v += 10;      // debug:  thread 'main' panicked at 'attempt to add with overflow'
                  // release: 4 (wraps modulo 256)
}

The debug panic is a gift — it catches the bug where it happens. The release wrap is the danger: the same code silently produces a wrong number in production. Debug builds run overflow checks (overflow-checks = true in the dev profile); release disables them along with assertions. The classic production bug is an index or counter that wraps to a small number and corrupts data. This is not hypothetical — it is the shape of real-world incidents where a length counter overflows and the program believes it holds a few items.

Rust therefore ships an explicit arithmetic API; every operation has four variants:

let a: u8 = 250;

assert_eq!(a.checked_add(10), None);            // Option: None on overflow
assert_eq!(a.wrapping_add(10), 4);              // modular wrap — deliberate
assert_eq!(a.saturating_add(10), 255);          // clamp at the boundary
let (sum, overflowed) = a.overflowing_add(10);  // (4, true) — both at once

The same quartet exists for sub/mul/div/abs. Choosing is a semantic decision: timestamps and IDs that must detect corruption use checked_* and handle None; hash functions and ring buffers want wraparound and use wrapping_*; clamping to a boundary is right for physical quantities (volume, percentage). Dividing by zero is always a panic, in every profile — there is no wraparound answer for it.

The compile-time side deserves mention: overflow in a const context is a compile error, not a runtime panic:

const OVER: u8 = 255_u8 + 1;   // error[E0080]: evaluation of constant value failed

How to guard against the release-only wrap in practice. First, run your test suite under cargo test --release at least once — bugs that hide in profiles love CI that only tests debug. Second, treat as-casts plus arithmetic as a review target: x as u8 * 2 wraps silently in both profiles. Third, for anything counting untrusted input sizes, checked_* with an error path is the professional default. Overflow semantics are profile-dependent behavior — the same source code genuinely means different things in debug and release, and an interviewer asking "what happens when a u8 exceeds 255?" is probing exactly whether you know the two answers.

There is a middle setting between the two defaults, and production teams use it: keep overflow checks on in release and pay for them in speed.

[profile.release]
overflow-checks = true   # panic on overflow even in release

The trade is quantifiable — checks add a compare and branch per operation, which measures as a low-single-digit percentage on arithmetic-heavy code and is usually unmeasurable on I/O-bound services — in exchange for a panic with a full backtrace instead of a silently wrong number. Teams shipping financial or capacity arithmetic often enable it; teams shipping hot numeric kernels usually leave it off and use checked_* in the few places that need it. Either way you have made the decision rather than inherited it.

The lint route targets the same risk at the call site: clippy::arithmetic_side_effects (a restriction lint, enabled per module with #[allow]/#[deny]) flags every bare + - * / % on integers, forcing each one to be a deliberate checked_, wrapping_, or saturating_ call. It is aggressive — it will flag most code — but for a payment or quota module it converts "did we think about overflow?" from a review question into a compile-time one.

Underneath all of these is the property worth stating in an interview: overflow in Rust is defined behavior in every profile — a panic, a wrap, or a compile error, never undefined behavior as in C — so the choice of which defined behavior you want is a design decision you own.