Hacker News Reader

Comment by eudox | Hacker News Reader

Those are two different bindings. That is,

  fn main() {
    let x = true;
    {
      let x = false;
    }
  }

Since you don't use let for assignment, it's a non-problem. And it can be useful when you're doing some computation where you want to keep intermediate variables (for debugging or clarity), and rather than think of the proper name for each, you just successively bind the same name.

View on HN

I know a lot of people really like shadowing. I obviously don't. GHC has an option to emit a warning and if Rusts compiler adds one for it as well (maybe it has one by know? I don't know) I guess I'm okay with it.

Clippy has a lint, but it's not turned on by default, even in Clippy.

We have three, in fact, which disallow various kinds of shadowing. For example, some people like `let x = <expr containing x>` shadows but not `let x = <totally unrelated>`. But everyone has wildly different style choices here so we leave all three off by default and you can turn them on if you want. I have yet to see a bug in Rust code caused by shadowing, though.

Very useful indeed when you want a canonical or corrected (or otherwise "improved") version of a value and want to make sure that the original can't accidentally be used in what follows (which can be a hard to detect bug).

Yes, a common refinement pattern in code is (pseudocode):

  def fn(object):
    let object = predicate(object) ? modify(object) : error();
    // do something with the refined object

Or something along those lines.

  Can I write
   let x = 1;
   let x = x + 1;
?

Yes.

And is the behavior exactly the same as it would be if I omitted "let" on the second code line? If the answer is yes, isn't it just mutability with different syntax then?

I would guess shadowing wouldn't affect values shared with a different thread, because it's technically a new value, but in single-thread use it would be equivalent to assignment.

> I would guess shadowing wouldn't affect values shared with a different thread...

That is actually a big deal, though.

It doesn't have the same semantics, because even after introducing the new variable, it is still immutable. So you cannot accidentally modify the new variable. e.g.,

  let x = 1;
  let x = x + 1;
  x = 99; // Error: you can't accidentally modify the immutable variable `x`

  let mut x = 1;
  x = x + 1;
  x = 99; // Ok

You can even turn back a mutable varaible into an immutable variable, like this:

  let mut x = 1;
  x = x + 1;
  let x = x;
  x = 99; // Error: `x` became immutable

This can be useful to "pin" the variable after a large number of calculations done to it.

The behavior is not the same. It's a new variable, entirely. So you'll have two integers on the stack, one of them is not accessible any more. You can see this difference if you add a scope around the second x, and then print the value of the original x after it goes out of scope.

Consider this program:

    fn main() {
        let x = 5;
        let r1 = &x;
        let x = x + 1;
        let r2 = &x;
        
        println!("r1: {:p}", r1);
        println!("r2: {:p}", r2);
    }

This will print something like

  r1: 0x7fff955e3dfc
  r2: 0x7fff955e3dec

Note that while you can't access the original x, it's still there, and references to it still work. Because the value of x was copied, not mutated.

Also, given compiler details like SSA, I'd argue that in a certain sense, mutation is similar to this, rather than this being similar to mutation...

  > isn't it just mutability with different syntax then?

For one thing, in order to take a mutable reference to a binding, that binding must be declared as `mut`.

    let mut a = 2;
    let b = 3;
    let x = &mut a;
    // let y = &mut b;  // error: cannot borrow immutable local variable `b` as mutable

Reply on news.ycombinator.com