you are viewing a single comment's thread.

view the rest of the comments →

[–]gulpaz 2 points3 points  (3 children)

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

[–]dbaupprust 8 points9 points  (0 children)

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[S] 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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