[lnenad]

When did shadowing become a feature? I was under the impression it's an anti-pattern. As per the example in the article

> 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.

[lolinder]

> Replacing the value of one variable constantly throughout the code could lead to unpredictable bugs.

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.

[lnenad]

> 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!

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.

[lolinder]

> 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.

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!

[mk12]

It’s a trade-off.

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.

[pkulak]

And on the whole, I prefer shadowing. I’ve never had a bug in either direction, but keeping everything immutable without shadowing means you spend all your brain power Naming Things.

[lnenad]

I mean that's a really fake problem. How many times per line of code do you actually need to name variables and how many of those times you're shadowing a previously defined var. I'm guessing a very small amount.

[lolinder]

It's not just the naming things, it's also what you do after you've named them—if you can't shadow a name then you are stuck both coming up with new names and sifting through all the existing names in your autocomplete to try to remember which one is the real one at this point in the code. Get it wrong? There's a bug.

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.

[pkulak]

It absolutely depends on the language and how heavily it encourages immutability. For example, Rust and Elixor allow 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.

[polanas]

In case of rust, it actually happens quite often. I find myself rarely needing to use mut, instead using functional approaches such as iterators and expressions. So a high percentage of the code is let statements

[lolinder]

Exactly. Shadowing is a super important complement to Rust's immutability. Without it immutability would be less useful and therefore less used.

[drougge]

I think it's worth pointing out that the example in the article contains a bug caused by not having shadowing: "const foo3 = try foo.addFeatureB();" should not be using the original foo, but foo2.

[jay_kyburz]

I don't know zig at all, but why is the author trying to declare foo as const 3 times. Surely you would declare it as var with some default value that means uninitialized, then try and put values in it.

[lolinder]

It's probably a Zig antipattern, but it's a very common Rust pattern. Shadowing in Rust allows immutability to be ergonomic, and lack of shadowing discourages immutability.

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.

[jay_kyburz]

Oh, I just read the rust doc and its says "once a value is bound to a name, you can’t change that value." but I've thought of immutability the other way around, once a name has a value, it can't be changed.

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.

[error503]

There is a distinction between the variable itself and its name. Const (and Rust's immutability-by-default) ensures that the variable does not change after assignment. This holds true even as references to it are passed to other functions or stored for later use. You "can't" accidentally pass a reference to that variable which will then be unexpectedly mutated a dozen calls deep into a library function you didn't write.

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.

[saithound]

Shadowing always has been a feature, doubly so in languages which lack linear types.

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.

[nine_k]

Said promise should also be checked for sanity. E.g.

  for i in range(N) {
    for i in range(M) {
      # Typo; wanted j.
      # The compiler should complain.
    }
  }

[Maxatar]

The Rust compiler would complain in this case that the initial i variable is unused. Unused variables should be named with an underscore, _.

[dpc_01234]

Shadowing is a feature. It's very common that given value transforms its shape and previous versions become irrelevant. Keeping old versions under different names would be just confusing. With type system there is no room for accidental misuse. I write Rust professionally for > 2 years, and years before that I was using it my own projects. I don't think shadowing ever backfired on me, while being very ergonomic.

[lnenad]

Depending on which language you are using shadowing could lead to either small issues or catastrophic ones (in the scope of the program). If you have Python and you start with a number but end up with a complex dict this is very different than having one value in Rust and a slightly different value which is enforced by the compiler.

[Maxatar]

Don't see how it could introduce bugs. The point of replacing a variable is precisely to make a value that is no longer needed inaccessible. If anything introducing new variables with new names has the potential to introduce subtle bugs since someone could mistakenly use one of the variables that is no longer valid or no longer needed.

[sjburt]

When you are modifying a long closure and don’t notice that you are shadowing a variable that is used later.

I know “use shorter functions” but tell that to my coworkers.

[zamalek]

The example given isn't that great. Here's a significantly more common one:

    var age = get_string_from_somewhere();
    var age = parse_to_int(age);

Without same-scope shadowing you end up with the obnoxious:

    var age_string = get_string_from_somewhere();
    var age = parse_to_int(age_string);

Note that your current language probably does allow shadowing: in nested scopes (closures).

[chrisco255]

Changing the type on a value is an anti-pattern, in my opinion. It's not obnoxious to be explicit in your variable names.

[zamalek]

That implies that Hungarian notation is not obnoxious? Sure, that's a fine opinion to have, but I guarantee it is an exceedingly rare one.

[zozbot234]

If you're writing in a language without strong type checking, Hungarian notation makes sense.

[physicles]

Over the years, I’ve wasted 1-2 days of my life debugging bugs caused by unintentional variable shadowing in Go (yes, I’ve kept track). Often, the bug is caused by an accidental use of := instead of =. I don’t understand why code that relies on shadowing isn’t harder to follow. Wish I could disable it entirely.

[lolinder]

> Often, the bug is caused by an accidental use of := instead of =.

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.

[lnenad]

> There are lots of good explanations in this subthread for why shadowing as a concept is great

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).

[lolinder]

You're saying ergonomics aren't a good explanation? The entire point of a programming language over writing machine code boils down to ergonomics! You've got to do better than "it's just ergonomics" when your argument for a language to ban shadowing is also "just ergonomics".

The debate here is about which one truly has better ergonomics!

[pcwalton]

You can (assuming you're talking about Rust)! Just use Clippy and add #[deny(clippy::shadow_reuse)]: https://rust-lang.github.io/rust-clippy/master/#shadow_reuse

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.

[mk12]

This is another big difference between Rust and Zig. Rust lets you have it both ways with configuration. Zig places much more value on being able to read and understand any Zig code in the wild, based only on “it compiles”. Rust’s “it compiles” gives you lots of information about safety (modulo unsafe blocks), but very little about certain other things until you’ve examined the 4-5 places which might be tweaking configuration (#[attributes], various toml files, environment variables, command line flags).

[antonvs]

It’s been a feature in languages for at least half a century. Scheme’s lexical scoping supported it in 1975, and Lisp adopted that.

[lnenad]

Yeah, it's a feature of a language, doesn't mean we are forced to use it.

[antonvs]

You asked when it became a feature. I answered that.

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.