4 ms·

In the 9th code snippet that's not an example of variable shadowing, it's just variable reassignment. Shadowing involves variable assignments in different scope

In the 9th code snippet that's not an example of variable shadowing, it's just variable reassignment. Shadowing involves variable assignments in different scopes. https://en.wikipedia.org/wiki/Variable_shadowing https://en.wikipedia.org/wiki/Variable_shadowing edit: I should've called it "variable redefinition" or something like that I guess, my mistake. Reassignment is definitely not the correct terminology for this. Still, it's not shadowing because the new binding of 'x' is not effectively shadowing some other 'x' name, it's just taking its place in the same scope. And this is orthogonal to the memory allocation of the assigned objects.

stormbrew 6y ago
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&edition=2018&gist=8af2f63e25b8bc8bfdb43c1908cf7da4 https://play.rust-lang.org/?version=stable&mode=debug&editio...
- mcsalgado 6y ago
  Oh interesting, I see now! Thanks for clearing this up.
bysin 6y ago
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 https://en.wikipedia.org/wiki/Variable_shadowing#Rust
red2awn 6y ago
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.
kd5bjo 6y ago
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.
powersnail 6y ago
Isn't variable reassignment a special case of variable shadowing, where the new scope closes at the same place as the parent scope?
psyklic 6y ago
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-rust/6441/12 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-mutability.html#shadowing https://doc.rust-lang.org/book/ch03-01-variables-and-mutabil...

stormbrew 6y ago

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&edition=2018&gist=8af2f63e25b8bc8bfdb43c1908cf7da4 https://play.rust-lang.org/?version=stable&mode=debug&editio...

mcsalgado 6y ago
Oh interesting, I see now! Thanks for clearing this up.

bysin 6y ago

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 https://en.wikipedia.org/wiki/Variable_shadowing#Rust

red2awn 6y ago

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.

kd5bjo 6y ago

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.

powersnail 6y ago

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

psyklic 6y ago

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-rust/6441/12 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-mutability.html#shadowing https://doc.rust-lang.org/book/ch03-01-variables-and-mutabil...