var keyword for mutable locals only

[dherman]

Issue #1273 proposed let mut for mutable locals and mut for mutable fields. let mut is more verbose than a single keyword and also breaks column alignment. People rightly didn't like the idea of var for mutable field declarations. But I think nobody suggested the idea of using var for mutable local declarations and mut for mutable field declarations:

let x = 7; // declaration of immutable variable x
var y = 7; // declaration of mutable variable y
type point = { mut x: int, mut y: int }; // declaration of mutable record type

Dave

[nikomatsakis]

I have to confess, I at first thought that we should use the same keyword for mutable vars and mutable fields, but var does read kinda' well (though I don't dislike let mut)

[ssylvan]

I think it's a feature that declaring a mutable variable is ever-so-slightly more cumbersome than an immutable one. I can see programmers using just "var" to be "consistent" or because "var" would be more powerful (don't have to change it if you decide to mutate later). Then you end up with less readable code overall.

Not suggesting that Rust should be a serious bondage & discipline language, but a gentle nudge in the right direction is morally justifiable, I think (i.e. the rule would be "for safe code, the safer constructs should be less noisy than the more powerful but easier-to-mess-up constructs").

[bstrie]

On one hand I like this, since it would remove the visual ambiguity from this form:

let mut x = 4,
    y = 8;  // is y mutable or not?

But I'm inclined to side with ssylvan. Declaring mutables doesn't exactly need to be ugly, but I think it makes sense if they're ever-so-slightly less convenient to create than immutables, if only by a single keystroke. The activating keyword also needs to be distinctive, and (IMO) var is too widely used as a generic variable declaration keyword to specifically convey mutability in a language that prides itself on immutability-by-default. And think of the poor C# programmers, for whom var is our let!

I still like the idea of replacing let mut with a single keyword, so as to address the code snippet above, but is there any reason for introducing a new keyword when mut itself would suffice, as per the original proposal in #1273?

[nikomatsakis]

@pcwalton pointed out a problem with just using mut: there is an ambiguity with record literals and block expressions that requires arbitrary lookahead to resolve.

{ mut x: int ...

Record literal, or block with local variable?

[eholk]

I could see a lot of programmers just learning that var is how you declare variables in Rust, and not using let at all. After all, var is how you declare local variables in languages like JavaScript. I'm inclined to think this is a good thing about this proposal.

I overheard someone point out yesterday that now let and var would have the same length, which would be nice for alignment.

[pcwalton]

I'm somewhat indifferent, but I somewhat prefer var, because it's shorter. Making mutability annoying isn't a desirable goal as I see it. (Indeed, I tend to think the role of a programming language should not be to make anything annoying—just clear, which isn't the same thing.)

[bstrie]

While I'm still wary of using let and var together (just like Javascript, but 100% different), it would be much less of an issue if there were a lint pass to detect variables that are declared as mutable but never actually mutated.

[brson]

There is a plan to make mutability a part of the type. Does that affect locals and make this irrelevant?

[Dretch]

How about:

val x = ... // immutable (val-ue)
var y = ... // mutable (var-iable)

Like in Scala.

[graydon]

I think @brson is right and this issue vanishes once we move mut into a type, i.e. you get let x = mut 10;

Closing this issue for now; reopen if you think I'm wrong!

[nikomatsakis]

I am not sure about this. I like the idea of moving mut into the type, but I don't know that it's a "done deal"---there may be lingering weirdness in there. In any case, I never considered that one might write let x = mut 5, I always assumed you'd write let mut x = 5 just as today; the "mutability-ness" of the type of a variable would come from the way it was declared, not the value being assigned to it.

To do otherwise would seem to imply that if you have an array x of type [mut int] and you write let y = x[0] then y is mutable? Or something? That seems undesirable.

[brson]

@Dretch I don't love val/var because they are not distinct enough, though the Scala precedent is nice.

I share @eholk's concern about people learning to use var by default. The way it works now I tend to declare everything as immutable, then the compiler reminds me it should be mutable, then I type mut. This is arguably good behavior that you would be less inclined to with a var/let split - typing var and let are equally difficult but you can't even type let mut without typing let.

But I don't h ave a preference and I do appreciate when I can compose functions entirely of statements beginning with three-character keywords.

[dherman]

@nikomatsakis In particular, it makes sense to me that the rules about single-assignment should come from the mutability of the declaration rather than the type. Subtly changing the assignment rules based on type smells funny to me.

I'm inclined to agree with @pcwalton that we shouldn't penalize programmers from using a mutable binding if that's what they want. As for the concern about people unnecessarily using var, we could add an optional warning that complains if a var binding is singly-assigned. But I also think that we can set precedents for good style in rustc and the standard library.

Dave