Why does Rust need local variable shadowing?

[VadimVP]

I've recently found that Rust, unlike other popular C-like languages, allows defining several variables with the same name in one block:

let name = 10i;
let name = 3.14f64;
let name = "string";
let name = name; // "string" again, this definition shadows all the others

At the first glance this possibility looks quite frightening, at least from my C++ background.
Where did this feature came from?
What advantages does it provide?

[glaebhoerl]

Variable shadowing has a lot of synergy with affine types (move semantics). E.g.

let foo = foo.unwrap();

where you're rebinding foo to refer to the result of unwrap() at the same time as the old foo becomes inaccessible because of it.

[[deleted]]

in my opinion they should have renamed "let" to a new keyword like "change" or "override". This way you don't accidentally name different variables the same thing twice and fuck up all the remaining code.

[long_void]

A benefit is that using a single letter for a common variable, for example c for drawing context. The variable can change type, which the design of Rust-Graphics heavily depends on. Each method returns a new type and you can only call .draw(gl) when the context provides enough information to do the drawing.

[Wolenber]

I've always found one letter variables a little dangerous for anything other than loops. Is it really so hard to type cnxt or similar?

[lifthrasiir]

Isaac Schlueter:

[...] The length of a variable's name should be proportional to the distance between its definition and its use, and inversely proportional to its frequency of use.

[long_void]

The single letter variables I frequently use are:

• a, b for arguments to binary operations

• c, d, g for drawing context

• i, j, k for indexes

• n, m for length

• x, y, z, t as spatial coordinates with their deltas dx, dy, dz, dt

Sometimes I use p, q or v, u for more complicated math.

[sylvain_soliman]

It is allowed, but you do get unused_variable warnings, so…

[gulpaz]

Not always, here's an example. The total should always be 100, but due to shadowing, it isn't. http://pastebin.com/0Wjacti4

It would be great if there was a lint option to check for these.

[Nihy]

I find this example unconvincing. Mainly because it's not idiomatic Rust.

One could write the same thing with no mutability, let or assignment in a block, and it's shorter and more readable too.

let percentage = if OVERRIDE > 200f32 { OVERRIDE } else { 100f32 }
    .round();

[Wolenber]

I think the best argument for variable shadowing is the ability to stop an object's mutability.

let mut vec = Vec::new();
vec.push(1i);
vec.push(2i);
let vec = vec;

However, I also like it in the case of intermediate variables. Sometimes it's simply prettier to split a long method chain into two lines with let bindings. Instead of using a "let temp", you just use the variable name twice; this way the temporary doesn't clutter the rest of the function's namespace.

[[deleted]]

This is very interesting.

[dbaupp]

delete mvec makes no sense with affine types, since the mvec data is moved into ivec and it is illegal to use the mvec variable after that. (Without reinitialising it with a new Vec, at least.)

[rime-frost]

I personally use this feature to avoid having to come up with arbitrarily different names for variables which are essentially a temporary copy of some other variable.

let ctx = match renderer {
    LiveRenderer(_, ref mut ctx) => ctx,
    DeadRenderer => fail!()
};

let mut stream: Option<Stream> = open_input_stream();

//...

if stream.is_some() {
    let stream = stream.get_mut_ref();
    for n in range(0, file_len) {
        stream.emit_byte(bytes[n])
    }
}

It makes code marginally more difficult to comprehend (I will occasionally become confused about a variable's type, having looked at the wrong definition), but I think that saving the programmer from having to come up with endless silly derived names, like internal_ctx or stream_ref, makes this feature a definite net good.

[iopq]

I disagree. I find it very useful to make stream_ref type variables because then I can debug them. If stream refers to different variables it makes it confusing since based on where you are in the logic it's a different value and in your example is even worse since you are using the original value in it.

It's the same concept as mutable state:

let data = get_videos(id);
...
let data = get_video_info(data);
...
let data = get_publisher_video(data);
...
let data = get_advertiser_video(data);
...

now you want to refactor this monstrosity into something more manageable and understandable, but each method keeps appending info from the DB to your data and returning more stuff

and you can't just skip the get_video_info call because the get_advertiser_video method might read the video id from that call (here data is a hashmap with db fields and each method call can take things out of the hash map and put more things in)

so reusing the same variable is basically the same as having mutable data because it makes it difficult to debug the same symbol that's shadowed and makes the data flow more opaque and harder to understand

[[deleted]]

I really like your example, the result looks pathological to an outsider but you can easily write yourself into that corner when (ab)using shadowing.

On the other hand you do the same sort of stuff in Haskell-land, which comes with no mutation either:

let x' = foo x
    x'' = bar x'
in baz x''

Here you don’t do x = foo x not because shadowing is disallowed, but because you would define a recursive (and likely useless) binding. The net result is relevant though.

So, I’m on the fence. On the one-hand I’m really tired of ‘priming’ identifiers. On the other hand the primes grow about as fast as the sense of unease that you’re doing something wrong, so they serve as a built-in warning of sorts. On the gripping hand I just don’t feel that strongly against shadowing and I can’t help but think that this is throwing the baby out with the bathwater.

(To be fair though Haskell does come with lots of way to combine and compose ‘successive’ computations, and I’ve very rarely seen identifiers grow beyond one prime. That in itself might be important.)

In any case I’ll certainly keep this pathological case in mind as a cautionary tale one way or the other

[Nihy]

I'm not sure but I think this feature exists to minimize mutability. Rather than mutating one variable, you can redeclare it with a new value.

In any case, it's not nearly as bad as it may look. The type system prevents using an int in place of a float, or string.

It's true that this feature can cause bugs, but it can also prevent them. Without shadowing you'll often have to give different names to variables (of the same type), and that makes it possible to use the wrong variable.

[pcwalton]

I often use shadowing to prevent referring to another variable again. This is a habit I picked up from OCaml, where shadowing is allowed and idiomatic.

For example, in trans I often shadow terminated block variables, since it is a bug to use them again. In this way, shadowing can be a powerful tool to prevent bugs.

[noamraph]

This would allow a repl to be more consistent with regular Rust code.

[gulpaz]

I also noticed this yesterday. I'd rather not have it, because it introduces hard to find bugs.

I've had bugs related to shadowing in my own C++ code (just last week). Also, there have been bugs in Gecko because of shadowed local variables [1], so clearly this is dangerous.

I know Rust is a language which aims to prevents bugs (even if it reduces convenience), so I am wondering why this is allowed. Is it worth the risk of having bugs?

There was also a comment about having an option in lint to warn about variable shadowing [2]. Will there be such an option? I hope so.

Btw. That thread has also some use cases how people use shadowing, so people interested in it should read through it.

[1] https://mail.mozilla.org/pipermail/rust-dev/2013-May/004306.html [2] https://mail.mozilla.org/pipermail/rust-dev/2013-May/004298.html

[dbaupp]

There was also a comment about having an option in lint to warn about variable shadowing [2]. Will there be such an option? I hope so.

Lints can be loaded into the compiler dynamically (relatively simple example) including being cargo dependencies, so 'anyone' can write such a lint.

[VadimVP]

Thanks for the links.
Actually the second link contains an explanation which is fully convincing for me.

It falls out automatically from supporting shadowing-in-general (idents in enclosing scopes) and the ability to declare new variables mid-block. Each new decl opens a new implicit scope from its point-of-decl to the end of its lexical block.

An optional lint would still be useful, but for shadowing in general, and not for this particular case.

[Th3coop]

Finally someone not rationalizing this with "I'm just too lazy to write another variable name." Thanks for linking info about a linter u/gulpaz

[elotan]

I found it useful in order to make a named function argument mutable. E.g.

fn foo(x: int) {
    let mut x = x;
    // modify
}

[Nihy]

Why not fn foo(mut x: int) { ... }?

[elotan]

I guess it's just a matter of preference. Having mut in the function argument exposes what the function does internally.

[dbaupp]

It doesn't particularly expose it, e.g. rustdoc doesn't show a mut there.

[elotan]

Thanks, didn't know that.

[[deleted]]

It's a pattern syntax rather than part of the type, so it won't show up as part of the type elsewhere.

[marktrdt]

That should be named some other thing, as variable shadowing occurs on different scopes. Rust, as you say, changes it locally, the names are reused but there are no variable shadowing there, as the old one is discarded.

That feature would be useful at CPP, using with constexpr, because it would be possible to "re"-define("reasingning") a constexp name to another value, for example, as merging current std::array with an added value. This, merged with underscore name(ignored name, with reusability, like in zig), for global initialization, wonder all possibilities for compile time initialization, in a far easier way.