3 ms·

This is not shadowing. Or at least not any definition of variable shadowing that I've ever seen. This is just redeclaring or redefining the variable. Variabl

This is not shadowing. Or at least not any definition of variable shadowing that I've ever seen. This is just redeclaring or redefining the variable. Variable shadowing is allowing a variable of the same name as an existing variable, but within a different scope. The difference in scope is absolutely critical - because the shadowing happens within some scopes, but not within others - there are still two instances of the variable, and both values are still kept, but which one is visible depends on the scope. Basically, to quote the def - "At the level of identifiers (names, rather than variables), this is known as name masking. This outer variable is said to be shadowed by the inner variable, while the inner identifier is said to mask the outer identifier."

asimpletune 3y ago
> This is not shadowing. Or at least not any definition of variable shadowing that I've ever seen. Then this is just a flavor that you haven't seen. https://doc.rust-lang.org/book/ch03-01-variables-and-mutability.html#shadowing https://doc.rust-lang.org/book/ch03-01-variables-and-mutabil... > Variable shadowing is allowing a variable of the same name as an existing variable, but within a different scope. By different scope you mean there's an inner scope and then there's an enclosing scope, where the inner scope has access to the outer scope but not vice versa. This (Rust's shadowing) more or less works and feels the same, but the difference is that additionally allows variable shadowing to be done within the same scope. > The difference in scope is absolutely critical I would agree with you if the way that Rust implements shadowing took away the ability to do what you're talking about, but that remains in place. You just have the extra option of redefining an immutable variable within the same scope as well, so it's purely additive. Personally I don't think there's anything bad with variable shadowing within the same scope, as at times it can be useful and help avoid mistakes. It's like, there are times when you are fine with original variable never coming back into scope, and you now have the ability to do that. I don't see any problems or dangers from that, especially if normal closure/block scope variable shadowing remains.
- horsawlarway 3y ago
  I'm not claiming that rust doesn't have shadowing, just that redefining a variable in a single scope is not really what I would call shadowing. A shadow is obscuring an object that is still very present, just hidden. That object can be seen again by changing scope. If there's no way to get back to the original (or the only way back is through a different name), it's not a shadow, just a redefinition. That name doesn't have a shadowed copy, it just has a previous value. Nothing wrong with redefining a variable either, it's perfectly valid. It's just different than shadowing, in my opinion.
mrkeen 3y ago
Yes it is shadowing. Every line of code starts a new scope.
- horsawlarway 3y ago
  And a redefinition changes the lexical scope of a variable in a way that shadowing does not... Scope is not about lines, it's about visibility.

asimpletune 3y ago

> This is not shadowing. Or at least not any definition of variable shadowing that I've ever seen. Then this is just a flavor that you haven't seen. https://doc.rust-lang.org/book/ch03-01-variables-and-mutability.html#shadowing https://doc.rust-lang.org/book/ch03-01-variables-and-mutabil... > Variable shadowing is allowing a variable of the same name as an existing variable, but within a different scope. By different scope you mean there's an inner scope and then there's an enclosing scope, where the inner scope has access to the outer scope but not vice versa. This (Rust's shadowing) more or less works and feels the same, but the difference is that additionally allows variable shadowing to be done within the same scope. > The difference in scope is absolutely critical I would agree with you if the way that Rust implements shadowing took away the ability to do what you're talking about, but that remains in place. You just have the extra option of redefining an immutable variable within the same scope as well, so it's purely additive. Personally I don't think there's anything bad with variable shadowing within the same scope, as at times it can be useful and help avoid mistakes. It's like, there are times when you are fine with original variable never coming back into scope, and you now have the ability to do that. I don't see any problems or dangers from that, especially if normal closure/block scope variable shadowing remains.

horsawlarway 3y ago
I'm not claiming that rust doesn't have shadowing, just that redefining a variable in a single scope is not really what I would call shadowing. A shadow is obscuring an object that is still very present, just hidden. That object can be seen again by changing scope. If there's no way to get back to the original (or the only way back is through a different name), it's not a shadow, just a redefinition. That name doesn't have a shadowed copy, it just has a previous value. Nothing wrong with redefining a variable either, it's perfectly valid. It's just different than shadowing, in my opinion.

mrkeen 3y ago

Yes it is shadowing. Every line of code starts a new scope.

horsawlarway 3y ago
And a redefinition changes the lexical scope of a variable in a way that shadowing does not... Scope is not about lines, it's about visibility.