Ok. Shadowing has been a thing for a very long time. If you are in languages that use block scoping, yes, you could just build a new block and call it a day. No, that isn't ergonomic, though.
Not all variable shadowing requires block scoping. Like I said about rust, you can literally just redeclare the variable, even one that’s not mutable.
About ergonomics, I think it’s a matter of opinion. To me though it is very ergonomic. As an example, let’s say you get the users input, trim the length, and parse it as a number. Without variable shadowing you have 3 variables (like, inputResult, inputStr, inputNum) and all those variables are still accessible , potentially by accident, throughout your code.
If you just have one input variable that you redefine, then you don’t have to pollute the scope with variables or think of more names and you won’t accidentally use one of the intermediate ones elsewhere. To me that’s more ergonomic.
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."
> 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.
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.
Reading on how rust does it some. First search I'm finding is https://maxuuell.com/blog/how-not-to-shadow-variables, which amuses me to see that you can just redeclare variables in the same scope. That feels like a footgun in itself. The rest of the footguns listed there seem about right.
Is that how other languages are starting to do this?
And agreed that not polluting the scope is good. That is why mutating the variable was the preferred way for a lot of folks.
