Having variables with scopes that last longer than they're actually used and with names that are overly long and verbose leads to unpredictable bugs, too, when people misuse the variables in the wrong context later.
When I have `initial_foo`, `foo_feature_a`, and `foo_feature_b`, I have to read the entire code carefully to be sure that I'm using the right `foo` variant in subsequent code. If I later need to drop Feature B, I have to modify subsequent usages to point back to `foo_feature_a`. Worse, if I need to add another step to the process—a Feature C—I have to find every subsequent use and replace it with a new `foo_feature_c`. And every time I'm modifying the code later, I have to constantly sanity check that I'm not letting autocomplete give me the wrong foo!
Shadowing allows me to correctly communicate that there is only one `foo` worth thinking about, it just evolves over time. It simulates mutability while retaining all the most important benefits of immutability, and in many cases that's exactly what you're actually modeling—one object that changes from line to line.
When you have only one `foo` that is mutated throughout the code you are forced to organize the processes in your code (validation, business logic) based on the current state of that variable. If your variables have values which are logically assigned you're not bound by the current state of that variable. I think this a big pro. The only downside most people disagreeing with me are mentioning is related to ergonomics of it being more convenient.
If I'm understanding you right, this is just restating what I said as a positive thing. I stand by my assertion that it's not positive: you can always choose to leave previous states accessible by choosing different names. But if a language doesn't support shadowing then I don't have the capability to intentionally restrict myself from accessing those states. That means your language has less expressive power and fewer opportunities for me to build myself guardrails.
In some ways it's the opposite of unused variable warnings: if you disallow shadowing, the compiler is forcing you to leave variables accessible long after you need them. You're given no choice but to leave unused variables hanging around. With shadowing, I can choose the right path based on the situation.
> The only downside most people disagreeing with me are mentioning is related to ergonomics of it being more convenient.
As I said elsewhere, literally everything to do with programming languages is about ergonomics. Your arguments against shadowing boil down to ergonomics. You can't avoid having a debate by just saying "it's just ergonomics" when the debate that you started is which feature is more ergonomic!
Zig isn't Rust, so it makes sense that patterns in Rust don't translate well, but also I totally get TFA's preference for Rust in this case.
I thought the value of const was once you read const x = 1024, you can be sure that x is 1024 while its in scope, that subsequent code can make assumptions about the content of variable x. Or, when you see x in the code, you can jump directly to its definition and know what its value will be. Defined once and not changed.
Apparently I don't understand the value of const at all.
If you have shadowing, it simply means you can have a different variable with the same name later in the same (or child) scope, this usually must be explicit. The same name now refers to a different variable, but the original variable still exists and remains valid.
It's quite a useful pattern, particularly where the old value is no longer useful (for example transforming input), especially when using the old value might be valid code but would be a mistake.
If you allow shadowing, then you rule out the possibility of the value being used later. This prevents accidental use (later on, in a location you didn't intend to use it) and helps readability by reducing the number of variables you must keep track of at once.
If you ban shadowing, then you rule out the possibility of the same name referring to different things in the same scope. This prevents accidental use (of the wrong value, because you were confused about which one the name referred to) and helps readability by making it easier to immediately tell what names refer to.
That's not a fake problem, it's a problem I've actually run into on a regular basis on languages that don't have shadowing.
An awkward middle ground for me is Kotlin. It allows shadowing, but warns, so it might as well not be allowed. So you end up using lots of scoping tricks to avoid either making everything mutable, or having dozens of nearly-identical variables.
It is a promise to the reader (and compiler) that I will have no need of the old value again.
Notice that applying the naming convention you suggest does nothing to prevent the bug in the code you quoted. It might be just as easy to write
const initial_foo = Foo.init(); > const foo_feature_A = try initial_foo.addFeatureA(); > const foo_feature_B = try initial_foo.addFeatureB();
but it's also just as wrong. And even if you get it right, when the code changes later, somebody may add const foo_feature_Z = try foo_feature_V.addFeatureX();. Shadowing prevents this.
for i in range(N) {
for i in range(M) {
# Typo; wanted j.
# The compiler should complain.
}
} var age = get_string_from_somewhere();
var age = parse_to_int(age);
var age_string = get_string_from_somewhere();
var age = parse_to_int(age_string);
I know “use shorter functions” but tell that to my coworkers.
This is a distinctly Go problem, not a problem with shadowing as a concept. In Rust you'd have to accidentally add a whole `let` keyword, which is a lot harder to do or to miss when you're scanning through a block.
There are lots of good explanations in this subthread for why shadowing as a concept is great. It sounds like Go's syntax choices make it bad there.
Not really. All of them boil down to ergonomics, when in reality it doesn't bring a lot of benefit other than people hating on more descriptive variable names (which is fair).
The debate here is about which one truly has better ergonomics!
My position on shadowing is that it's a thing where different projects can have different opinions, and that's fine. There are good arguments for allowing shadowing, and there are good arguments for disallowing it.
But your antipathy towards the feature is misplaced. Several languages with the most rigorous foundations support shadowing: SML, Ocaml, Haskell, Scheme,
You're probably more familiar with languages that have unrestricted mutation, in which case something much worse than shadowing is allowed: changing the value of an existing variable.
> const foo = Foo.init(); > const foo2 = try foo.addFeatureA(); > const foo3 = try foo.addFeatureB();
It's a non issue to name vars in a descriptive way referring to the features initial_foo for example and then foo_feature_a. Or name them based on what they don't have and then name it foo. In the example he provided for Rust, vars in different scopes isn't really an example of shadowing imho and is a different concept with different utility and safety. Replacing the value of one variable constantly throughout the code could lead to unpredictable bugs.