5 ms·
Those are two different bindings. That is, fn main() { let x = true; { let x = false; } } Since you don't use let for assignment, it's a
by eudox 10y ago
Those are two different bindings. That is,
fn main() {
let x = true;
{
let x = false;
}
}
Since you don't use let for assignment, it's a non-problem. And it can be useful when you're doing some computation where you want to keep intermediate variables (for debugging or clarity), and rather than think of the proper name for each, you just successively bind the same name.
- sixbrx 10y agoVery useful indeed when you want a canonical or corrected (or otherwise "improved") version of a value and want to make sure that the original can't accidentally be used in what follows (which can be a hard to detect bug).
- eudox 10y agoYes, a common refinement pattern in code is (pseudocode): def fn(object): let object = predicate(object) ? modify(object) : error(); // do something with the refined object Or something along those lines.
- teamhappy 10y agoI know a lot of people really like shadowing. I obviously don't. GHC has an option to emit a warning and if Rusts compiler adds one for it as well (maybe it has one by know? I don't know) I guess I'm okay with it.
- steveklabnik 10y agoClippy has a lint, but it's not turned on by default, even in Clippy.
- Manishearth 10y agoWe have three, in fact, which disallow various kinds of shadowing. For example, some people like `let x = <expr containing x>` shadows but not `let x = <totally unrelated>`. But everyone has wildly different style choices here so we leave all three off by default and you can turn them on if you want. I have yet to see a bug in Rust code caused by shadowing, though.
- tormeh 10y agoCan I write let x = 1; let x = x + 1; ?
- steveklabnik 10y agoYes.
- tormeh 10y agoAnd is the behavior exactly the same as it would be if I omitted "let" on the second code line? If the answer is yes, isn't it just mutability with different syntax then? I would guess shadowing wouldn't affect values shared with a different thread, because it's technically a new value, but in single-thread use it would be equivalent to assignment.
- solidsnack9000 10y ago> I would guess shadowing wouldn't affect values shared with a different thread... That is actually a big deal, though.
- yokohummer7 10y agoIt doesn't have the same semantics, because even after introducing the new variable, it is still immutable. So you cannot accidentally modify the new variable. e.g., let x = 1; let x = x + 1; x = 99; // Error: you can't accidentally modify the immutable variable `x` let mut x = 1; x = x + 1; x = 99; // Ok You can even turn back a mutable varaible into an immutable variable, like this: let mut x = 1; x = x + 1; let x = x; x = 99; // Error: `x` became immutable This can be useful to "pin" the variable after a large number of calculations done to it.
- steveklabnik 10y agoThe behavior is not the same. It's a new variable, entirely. So you'll have two integers on the stack, one of them is not accessible any more. You can see this difference if you add a scope around the second x, and then print the value of the original x after it goes out of scope. Consider this program: fn main() { let x = 5; let r1 = &x; let x = x + 1; let r2 = &x; println!("r1: {:p}", r1); println!("r2: {:p}", r2); } This will print something like r1: 0x7fff955e3dfc r2: 0x7fff955e3dec Note that while you can't access the original x, it's still there, and references to it still work. Because the value of x was copied, not mutated. Also, given compiler details like SSA, I'd argue that in a certain sense, mutation is similar to this, rather than this being similar to mutation...