Var as alias for let mut

[medozs]

Hello Everyone,

I propose rust to implement var keyword as an alias for let mut. Some might think that’s unnecessary and I respect that, however, I think people who would like to create mutable variables by default without much cognitive thinking deserve that option too.

It would also make rust similar to 99% of language out there that has var being the default for mutable variables.

This is similar to the optional keyword return found in rust, where you don’t have to use it, but it’s available if you would like to.

The compiler can suggest to turn var into let if it’s not necessary.

It would make rust more natural as a programming language similar to most languages.

It’s doesn’t have to be named var, you can pick another to allow the function.

You might say that having let and var would make it confusing; however, Rust already has a similar situation with the const and let keywords, where both function as an immutable variable but they are implemented differently.

The var keyword can be denied by clippy as well if you would like too, that’s in addition to compiler warning in case the variable isn’t muted similar to let mut when it’s not necessary to change to const or let.

Making every Rust variable declaration immutable by default would greatly affect its adoption rate, it greatly reduces productivity in my opinion. I am certain that having both options(let and var) is the best way to go. I am not familiar with any other language that takes this immutable approach. It makes sense to have parameters immutable by default since people almost never mutate parameters; however, this is not the case with variables, and introducing var or similar keyword would be the solution for this concern. This would increase rust adoption rate in my opinion.

Thank you,

[sfackler]

return is not an optional keyword - it’s used to return early from a function.

How does writing var involve less thinking than let mut?

[ExpHP]

I question the very foundation of this argument; are there any popular languages out there that use var other than JavaScript?

Rust already has a similar situation with the const and let keywords, where both function as an immutable variable but they are implemented differently.

const is not an immutable variable. If you try to use const for immutable variables, you’re gonna have a bad time.

[medozs]

C# has var, Golang has var, and more

[rpjohnst]

are there any popular languages out there that use var other than JavaScript?

C#, Scala, Go (sort of), Swift, Kotlin, Java 10, probably more.

Not that I think Rust needs var- it’s hardly a burden when the entire language is designed around immutable-by-default already. The ability to shadow variables in the same scope, iterator-based for loops that handle mutation for you, etc.

[medozs]

I believe shadowing variables is a burden as well, I would rather have the option to declare a mutable variable by default in one word using var than having the option to mutate my immutable variable by re-declaring it.

[medozs]

How does writing var involve less thinking than let mut?

Because that’s not how it works in 99% of languages you work with. In addition, you require 2 words instead of just one.

[sfackler]

What’s not how it works? C, C++, and Java all have a concept of control over value mutability.

[medozs]

I mean that’s not the default mode of variable declaration and cognition in most of languages. In other languages you make a variable and reassign as you like, compilers can catch non mutated variables and tell us to change to constants.

[Centril]

Adding var was previously discussed here (closed) from the perspective of JavaScript. I concur with others that we should not add var and that it will make reading Rust harder.

For the purposes of making mutable bindings easier to deal with, I’ve proposed allowing let mut (a, b, ..) = tuple; as well as let mut [a, b, c, ..] = arr;. This is a significantly smaller change and fuses better with the language we already have.

[vorner]

I don’t think this would only clutter the language, but I prefer the fact you need to type more. It’s kind of syntactic salt ‒ it pushes you into the safer (and easier for compiler to optimise) constant by default. If you introduce var, people will forget let completely and will be writing only var, making the programs more error prone and slower. And they’ll probably disable these millions of warnings about variables not needing to be mutable.

And I do know of languages that go even further. Haskell, which just doesn’t have mutable variables at all.

[Centril]

And I do know of languages that go even further. Haskell, which just doesn’t have mutable variables at all.

Uhm, IORef?

A mutable variable in the IO monad

[vorner]

A mutable variable in the IO monad

Well, OK, but it’s like saying that Rust has mutable shared state, because it has unsafe cell. It’s a library type that breaks the rules, not feature of the language.

[medozs]

That’s a good proposal too.

[kornel]

The need for var depends very much on programming style, e.g. golang almost forces to write:

var x = 1;
if cond {
    x = 2;
}

instead of immutable

let x = if cond {2} else {1};

When const was added to JavaScript, a lot of people found that it’s possible to use const 99% of time (although it helps that JS’s const allows interior mutability).

So IMHO var is not that useful if you adopt a more functional programming style.

Whether it should be in Rust depends on whether Rust wants to be flexible and allow other programming styles. But given that Rust is already opinionated towards immutable by default it seems like the decision has been taken in favour of pushing towards functional style.

[Dylan-DPC]

I prefer to have let mut. It makes it clear that it is mutable.

[leonardo]

Having two equivalent ways to do something is generally bad.

[medozs]

Languages should be flexible in order for it to evolve. Let rust community decide by practice which keyword is used. Options are never bad. However, let mut with multiple variables is good option as well.

[medozs]

If it’s true that const is completely different than let and compiler can’t do anything about it then I think rust should create another meaningful and expressive keyword such as final or readonly or something. But I think compiler is possible to emulate let using const to a great degree based on usage.

[CAD97]

What do you think let and const do? I think that’s where the disconnect is.

Here’s (as I understand it) what they mean to Rust:

const NAME: declare a compile-time constant. This is a value that isn’t going to be different between builds; think const PI: f32 = 3.1415926535;. Typically used for module level constants, though usable within function contexts–though note that it still means the same thing, thus keeping the all-caps naming convention. The binding does not exist at runtime; it is inlined to its use sites.

let name: create a local binding. This is a value that is determined at runtime, and can differ between invocations of the function it is in based on the values of the right side of the assignment. For the most part, this should be your go-to default binding mode when writing functions.

let mut name: create a mutable local binding. This is equivalent to how let works except you are allowed to reassign the binding and to take mutable references to it.

---

In JavaScript it’s const or let for immutable or mutable bindings. In Java 10 it’s final var or var. In Rust, it’s let or let mut.

const is a different model, that the compiler has to know the single value of at compile time, and doesn’t exist at runtime, because it’s been inlined. In fact, rustc/LLVM will even do the same thing for let bindings and even more complicated expressions if it can fold it down to a constant expression.

There is no need to add final/readonly – let without mut already is that.

One last time: let and const are completely different tools in Rust. const in Rust is closest to static final in Java or constexpr in C++. let in Rust is final var in Java or const in JavaScript. Rust’s const is for constants in the mathematical sense: things that have always been and will always be the same.