Answer.

Shadowing is the ability to declare a variable with the same name multiple times in the same scope, where the new variable "shadows" the previous one. In languages without shadowing (C, C++), redefining a variable leads to an error or undefined behavior. Rust allows shadowing, and each variable is an independent object with a new type or value. This is convenient for stepwise transformations of a value — for example, turning a string directly into a number without coming up with new names.

Problem: on one hand — improved readability, preventing variable name bloating; on the other — complicated debugging if a variable is accidentally "shadowed" in a complex block and an unexpected result is obtained.

Solution: Shadowing is used only where it genuinely facilitates transformation and does not hinder readability. Each "let var = ...;" creates a new variable, leaving the old one unchanged outside the declaration block.

Example code:

fn example() {
    let x = "42";
    let x = x.parse::<i32>().unwrap();
    println!("x: {}", x); // x: 42
}

Key features:

Allows changing the type or value of a variable without changing its name
The value of the shadowed variable is not accessible after the new declaration
Shadowing is different from mutability: mutability is not needed for shadowing

Trick questions.

Can shadowing change the mutability of a variable?

Yes, you can "shadow" an immutable variable with a mutable one and vice versa:

let x = 5;
let mut x = x;
x += 1;

Does shadowing mean that the previous variable has been destroyed?

No, the values of the previous variable live until the end of the block where they were declared, but they become inaccessible by name.

Can shadowing be used inside a loop or within nested blocks?

Yes, each scope allows declaring variables with the same names, and these are different variables.

Common mistakes and anti-patterns

Shadowing with different types, which reduces readability
Accidental "shadowing" of a variable in deep nesting
Using shadowing to only change a value (better to use mutability)

Real-life example

Negative case

In the function, there's let result = expr1; ... let result = expr2;, where types differ.

Pros:

Convenient in transformations

Cons:

Hard to read, easy to make mistakes during debugging

Positive case

Shadowing is used only to change the type: first, a string is parsed, then it is assigned a numeric value.