The other parts:
Part 2: https://prog21.dadgum.com/24.html
Part 3: https://prog21.dadgum.com/25.html
Part 4: https://prog21.dadgum.com/26.html
Follow up: https://prog21.dadgum.com/37.html
Part 2: https://prog21.dadgum.com/24.html
Part 3: https://prog21.dadgum.com/25.html
Part 4: https://prog21.dadgum.com/26.html
Follow up: https://prog21.dadgum.com/37.html
- "Not being able to re-use names for values in functions". It's not a feature of functional languages, and thankfully many these days don't suffer from this limitation (see Erlang vs Elixir for example)
- "The lack of a simple dictionary type". Again, blame the terrible functional ecosystems of 2008.
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.
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.
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."
Then this is just a flavor that you haven't seen. 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.
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.
Every line of code starts a new scope.
Scope is not about lines, it's about visibility.