In Rust, the scope of a variable is limited to the block (curly braces {}). Declaring a new variable with the same name as an existing one in the current or outer scope is called shadowing. Shadowing allows changing the type and value of a variable without violating the concept of immutability.
Example:
let x = 5; // x: i32 = 5 let x = x + 1; // x: i32 = 6 (shadows the old x) let x = "hello"; // x: &str = "hello" (type changed)
Shadowing does not affect performance (it's purely a syntactical construct, compiling into different variables at the LLVM IR level), but it can significantly diminish code readability and maintainability, increasing the risk of logical errors.
Question: Does shadowing a variable lead to resource cleanup if the previous variable owned memory (e.g., String)?
Common answer: No, as the variable is simply "redefined".
Correct answer: Yes, when a variable is shadowed, the old value goes out of scope and, if it owned a resource, Drop is called. This ensures proper memory release.
Example:
let s = String::from("abc"); let s = 5; // String is released here (Drop called)
Story
A young developer used shadowing for a structure with an open file descriptor and, by shadowing the variable earlier than planned, accidentally closed the file before finishing work. This led to data loss in some cases.
Story
In one research project, shadowing was applied for variables of the same nesting level, causing developers to often get confused and refer to the "old" variable value, thinking it was still relevant.
Story
In a large server application, implicit shadowing of a struct field and a variable within a method caused a non-obvious error, where the field did not change, but a new local variable with the same name did. The error was discovered after a long search for the causes of the system's incorrect behavior.