There is effectively an implicit scope created by the let binding. In rust you can't reassign a variable without it being mut. The two `x`s are separate variables named x and are not at any point mutated. Reassignment would look like this:

    let x = 1;
    x = x + 1; // <- error[E0384]: cannot assign twice to immutable variable `x`
    let mut x = 1;
    x = x + 1; // ok!

This obviously matters very little for an integer, but it is relevant to more complex types.

You can actually see the scopes, and the progress of variable liveness, if you run the compiler out to the MIR intermediate language:

    fn main() -> () {
        let mut _0: ();                      // return place in scope 0 at src/main.rs:1:11: 1:11
        let _1: i32;                         // in scope 0 at src/main.rs:2:9: 2:10
        scope 1 {
            debug x => _1;                   // in scope 1 at src/main.rs:2:9: 2:10
            let _2: i32;                     // in scope 1 at src/main.rs:3:9: 3:10
            scope 2 {
                debug x => _2;               // in scope 2 at src/main.rs:3:9: 3:10
            }
        }

        bb0: {
            StorageLive(_1);                 // scope 0 at src/main.rs:2:9: 2:10
            _1 = const 1_i32;                // scope 0 at src/main.rs:2:13: 2:14
            StorageLive(_2);                 // scope 1 at src/main.rs:3:9: 3:10
            _2 = const 2_i32;                // scope 1 at src/main.rs:3:13: 3:18
            _0 = const ();                   // scope 0 at src/main.rs:1:11: 4:2
            StorageDead(_2);                 // scope 1 at src/main.rs:4:1: 4:2
            StorageDead(_1);                 // scope 0 at src/main.rs:4:1: 4:2
            return;                          // scope 0 at src/main.rs:4:2: 4:2
        }
    }

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Oh interesting, I see now! Thanks for clearing this up.

No, it really is shadowing. The second `let` allocates a new memory location in the activation record; all future mentions of the variable name will refer to the new location. The old location still exists, and may have references to it already; references that will continue pointing at the old allocation and will not see anything that happens to the new one. If the old value has a `Drop` implementation, it will run after the second allocation’s `drop()`. The two `let` bindings can even have completely different types.

In Rust, shadowing is when you "declare a new variable with the same name as a previous variable" [1] -- even in the same scope. It seems it "fell out" of how the original compiler was implemented, and there was more support to retain it than not. See: https://internals.rust-lang.org/t/history-of-shadowing-in-ru...

[1] The "Rust book" has a good explanation of shadowing, which contains a nearly identical example. See: https://doc.rust-lang.org/book/ch03-01-variables-and-mutabil...

There is literally a Rust example in your wiki link saying that this is shadowing. You can even redefine the variable to have a different type, how can this be reassignment.

In the wikipedia entry you provided, there's an example in Rust, similar to the 9th code snippet, that claims it is variable shadowing:

https://en.wikipedia.org/wiki/Variable_shadowing#Rust

Isn't variable reassignment a special case of variable shadowing, where the new scope closes at the same place as the parent scope?