Lesson 5. Bindings and Mutability

Mission link: Where mut goes, and what shadowing does, decide whether a function reads as a sequence of transformations or as a mutable blob. This is also where the borrow rule from lesson 3 gets its precondition: you cannot take &mut of something that is not mut.
Primary source: The Rust Programming Language, Variables and Mutability
Prerequisites: Lesson 3, Lesson 4

Warm-up

1. ▢ Why does taking &str rather than String in a signature cost callers nothing?

2. ▢ Why is s[0] refused on a String?

Know this

let creates a binding, and bindings are immutable by default:

let x = 5;
x = 6;                  // error: cannot assign twice to immutable variable

let mut y = 5;
y = 6;                  // fine

mut is a property of the binding, not of the type. There is no mut i32; there is a mut binding holding an i32. That is why lesson 3's rule needs it: &mut v requires v to be a mut binding, because a mutable borrow is permission to change what the binding owns.

Shadowing is a new binding, not a mutation

let spaces = "   ";
let spaces = spaces.len();      // a NEW binding, and a different type

The second let creates a new binding with the same name. The first still exists and is simply unreachable. Two things follow: the type may change, and no mut is needed.

That makes shadowing the idiomatic way to write a pipeline of transformations without inventing input_raw, input_trimmed, input_parsed:

let input = read_line();                 // String
let input = input.trim();                // &str
let input: u32 = input.parse()?;         // u32

Compare with mut, which cannot change the type and keeps one value changing under one name:

Use mut when a value genuinely changes over time, such as an accumulator or a buffer being filled. Use shadowing when you are converting rather than modifying. Both are ordinary Rust and neither is a trick.

Blocks are expressions

let category = {
    let score = compute();
    if score > 90 { "high" } else { "low" }
};

A block evaluates to its last expression, when that expression has no semicolon. The pattern above keeps score out of the surrounding scope, which is worth doing whenever a temporary exists only to compute one value.

The same rule explains why a missing semicolon changes a function's meaning: x + 1 returns, and x + 1; evaluates and discards, leaving the function returning ().

const and static

const MAX_RETRIES: u32 = 5;             // inlined at each use site
static GREETING: &str = "hello";        // one fixed memory location

Both require an explicit type and a value computable at compile time. const is what you want almost always. static matters when the identity of the memory matters, and a static mut is unsafe to touch, which stage 7 explains.

Neither is a let with extra letters: they live for the whole program and have no owner in lesson 1's sense.

One aside worth knowing now: integer overflow

let x: u8 = 255;
let y = x + 1;          // debug: panics. release: wraps to 0

Overflow panics in a debug build and wraps in a release build by default. That difference is deliberate, documented, and not undefined behaviour, unlike the equivalent in some other languages. When wrapping is the intent, say so with wrapping_add; when it must never happen, use checked_add and handle the Option.

It is mentioned here because it is the one place where "it worked in testing" has a language-level explanation rather than a logic one.

Practice

1. ▢ Which of these compile?

   // A
   let x = 5;
   let x = x + 1;
   
   // B
   let x = 5;
   x = x + 1;
   
   // C
   let mut x = 5;
   x = x + 1;
   
   // D
   let mut x = 5;
   x = "five";
   

2. ▢ Predict the two prints.

   let value = 10;
   {
       let value = value * 2;
       println!("{value}");
   }
   println!("{value}");
   

3. ▢ Which is better for this task, and why?

   // A
   let mut input = read_line();
   input = input.trim().to_string();
   
   // B
   let input = read_line();
   let input = input.trim();
   

4. ▢ Where does mut belong here, and what does each mut permit?

   fn fill(buffer: ??? Vec<u8>, count: usize) {
       for i in 0..count {
           buffer.push(i as u8);
       }
   }
   

fn fill(buffer: &mut Vec<u8>, count: usize) {

5. ▢ A test passes in a debug build and produces a wrong number in release. The code adds two u32 values from user input. Explain.

Real-world reps

• [ ] Write case D from practice 1 and read the error. It says the types differ, which is the clearest statement of what mut does and does not permit.
• [ ] Write the trim pipeline both ways and use a tool or your own reasoning to identify which one allocates.
• [ ] Tomorrow: overflow a u8 deliberately, run it once with cargo run and once with cargo run --release, and see both behaviours.

Going further

• Variables and Mutability: bindings, const, and shadowing with worked examples
• Data Types: the integer types, and the overflow paragraph
• Block expressions: why the last expression is the value
• Resources

Not landing? Reread the primary source at the top, since this lesson compresses it and compression is where understanding leaks. Check the glossary for any term that felt slippery.

If the lesson itself is unclear rather than the material, that is a defect: open an issue.