'var' as alias for 'let mut'

[pannous]

Now that rust compiles to wasm it would be nice to play to the Web community.

Thus a shortcut

var x=1;

for

let mut x=1;

would not only safe four keystrokes in each instance but also be nicer on the eyes and easier to grasp for newcomers. var for 'variable' already entails the concept of 'mutability', so it is a fit name.

[Centril]

Personally, I think that since we use mut elsewhere:

• in function arguments: fn foo(mut x: Bar) {..}
• for lifetimes, &'a mut Baz
• for let bindings as let mut as you've mentioned
  means that this is all consistent, which would stop being the case if we allowed var in one place.

Adding var to all places would also increase the burden on readers... now there are two forms you have to remember.

I could however see and support a bare mut being an alias for let mut. This is also equally short.

[eddyb]

Note that function arguments, let, if/while let, for and match use the same pattern syntax.

[eddyb]

Also "variable" doesn't mean "mutable", it means "the value may vary with each execution".
See also rust-lang/book#276 (comment).

[milibopp]

This is a bit of a false analogy, as var in JavaScript has some weird scoping rules, too. Rust's let is (kinda) like const in ES6 and Rust's let mut is like let in ES6. The superficial similarity suggested would be more confusing.

[ghost]

This may be unrelated but it would be nice if let mut (x, y, z) did the same as let (mut x, mut y, mut z). (I just post it here because it made me think that var (x, y, z) would act as let (mut x, mut y, mut z).)

I haven't really thought about the implications of such a thing, just throwing it out there.

[burdges]

It works, so does let Foo { ref mut x, mut y, .. } = .., but sadly you cannot destructure a Drop type to provide an alternative to droping it. #2061

[hadronized]

@whataloadofwhat you don’t want to mix external with internal mutability.

[cramertj]

With the match_default_bindings feature you can write let Foo { x, y, .. } = &mut ...; instead of let Foo { ref mut x, ref mut y, .. } = ...;

[mgattozzi]

@rust-lang/wg-wasm

I'm of the opinion of others here that var is not a good choice to add to the language. I'm not going to reiterate the above points as they cover most of what I think, but I do also want to bring up that this would be a breaking change in Rust and would require a new epoch since it's not a reserved word. I don't think we stand to gain anything from this change besides confusion and that is not worth starting a whole new epoch.

[fitzgen]

Also, const in JS is only about the binding, not the data referenced by the binding, so trying to draw parallels there comes up a bit short too.

Don't think this is a good idea based on what others have already said.

[koute]

I agree with @mgattozzi in that I don't think the additional keyword would pull its own weight, and it would do more harm than good. Rust is already essentially totally different than JavaScript, so introducing an extra keyword would hardly help.

[killercup]

let in Rust uses pattern syntax and mut is used in a lot of other places. I vote for closing this issue.

Now that rust compiles to wasm it would be nice to play to the Web community.

This is a very weird argument: IMHO, you should not use var in ES2015 and newer. let and const have far less surprising scoping rules.

[aidanhs]

Previous discussion: rust-lang/rust#2643

[Pauan]

@killercup Indeed, var is considered de-facto deprecated in ES2015.

It will still be supported indefinitely (for backwards compatibility), but the JavaScript community consensus is that var is bad and let / const is good.

---

As for this topic... I completely agree that we should try to help out JavaScript programmers, I think Rust has great potential for being a first-class citizen on the web.

I want Rust to succeed not just on the desktop and server, but also in web apps, Chrome / Firefox extensions, iOS, Android, etc. I applaud @pannous for their good intentions.

However, adding in var would make things more confusing, not less. Consider the situation if we added in var:

• JavaScript programmers will wonder why there is both var and let mut, and wonder what the differences are, and which one they should prefer to use.

• JavaScript programmers will wonder why they can use mut in function arguments and destructuring, but they can't use var

• Rust's var is different from JavaScript's var, because Rust's var is block scoped, and JavaScript's var isn't. Also, in JavaScript you can use a variable before it is defined, but in Rust you cannot.

• JavaScript programmers consider var to be bad, so they would have to be taught that it's completely okay in Rust.

• JavaScript programmers will wonder why let is immutable in Rust even though it's mutable in JavaScript.

• JavaScript programmers will wonder why const in Rust behaves completely differently from const in JavaScript.

• And of course Rust is dramatically different from JavaScript in many many ways (the most obvious is Rust's memory model), I doubt the lack of var is a deal-breaker for people trying to learn Rust.

Therefore, because of all those reasons, I think adding in var is a bad idea, especially because it would be inconsistent with JavaScript's var.

I say all of that despite the fact that JavaScript is the first language I learned, and I've been programming in JavaScript for over 11 years.

I am a JavaScript to Rust convert, and I think Rust having var would have made things worse for me, not better.

If we want to convert JavaScript programmers to Rust (and I think we do want that), then I think the best way is to create some well-made tutorials explaining the differences between JavaScript and Rust, helping JavaScript programmers understand tricky Rust concepts (such as memory and borrowing), and also explaining why Rust does things the way that it does.

In other words, a tutorial carefully designed for JavaScript programmers, explaining things from the perspective of JavaScript programmers.

[pannous]

based on eloquent consensus this chapter is hereby closed