add special syntax for mutable variable declarations

[boggle]

we just discussed this on irc and everybody on seemed to like this idea:

let x = 7 // declaration of immutable variable x
mut y = 7 // declaration of mutable variable y

This ticket serves as a way to track this idea and potentially implement it.

[nikomatsakis]

Reasons to make this change:

• immutable values can be implicitly copied into closures without fear of confusing people
• mutable values can still be copied via explicit capture clause
• feels analogous to struct fields and the like
• no more typing than before, just more clarity

[nikomatsakis]

I noticed that the words "mutable" and "local variable" do not appear in this bug! It took me a while to find it as a result. Therefore, I am adding this comment to make future searches easier.

[marijnh]

immutable values can be implicitly copied into closures without fear of confusing people

Not really. If you close of let x = {mutable foo: int};, you can still observe that a copy was made.

[nikomatsakis]

That's true. This is because vectors are unique pointers. I was tacitly assuming that the "no implicit copies" proposal is accepted, in which case (a) vectors would not be unique pointers and (b) unique pointers (and other structures with expensive copies) would require an explicit copy annotation.

[marijnh]

The example I gave did not contain any vector. But I guess it would make sense for mutable structure types to also no longer be implicitly copyable.

[nikomatsakis]

Yes, you are right, it did not. I misread it as [mutable...] not {mutable:}. But anyway it would still be addressed by the no implicit copies proposal, which is specifically aimed at preventing explicit copies of (potentially) mutable data like this. (of course @{mutable f: ...} would be implicitly copyable, as it is simply a pointer)

[ssylvan]

Why not just use the existing "mutable" keyword? Even requiring an explicit type wouldn't be so bad, but some simple shorthands would help (e.g. "let x : mutable" would constrain the type to be mutable, but would get the rest of its type from inference (e.g. "mutable int" or whatever)).

I kind of like that you have to type a few more characters for mutable variables. It adds some slight pressure to avoid them.In my one simple rust app (a raytracer) I found that over 90% of local variables were immutable.

Also, IMO, mutable variables are a significant detriment to readability. The more times a variable is changed, the more "what-ifs" you have to consider when interpreting its potential values when reading the code. Making it slightly painful (though not too painful!) to allow mutation could be a good thing.

[brson]

Maybe just use mutable in place of let, like mutable x: int = .... That places 'mutable' in the same position relative to the identifier as in records.

[nikomatsakis]

@brson this was the original proposal. I just wanted to change the mutable keyword to mut because mutable is too long.

[brson]

oh. carry on then

[graydon]

I'm ok with:

• Switching mutable to mut, It's already chatty enough when writing record fields.
• Making let x = ... immutable, requiring mut x = ... to declare a mutable local.

Though var might be a bit more familiar. {var x: int, y: int} clear enough? Or should we keep it as {mut x: int, y: int}?

[brson]

I like var because it is more familiar for locals and because mut sounds ugly.

[nikomatsakis]

I don't have a strong opinion on the choice of keyword, though I'd rather use the same one for all mutable things (i.e., {var x: int}).

[marijnh]

+1 for var

[graydon]

wishy-washy on the matter. I kinda like that mut is ugly, but var seems tolerable if it's the price for making more locals immutable by default :)

[marijnh]

(As an aside, we already distinguish between mutated locals and immutably used ones—the mut_map that mut.rs produces—so no further optimizations will result from this. For expressing intent, it's probably very useful.)

[ssylvan]

My preference would be to make it roughly "twice as ugly" as immutable locals, whatever that means :-).. I'd want it to be pretty damn ugly so people would avoid it if they don't really need it, and so that it stands out better when you read it, but not ugly enough that you'd feel it was clunky for the few cases where you do need it. For me that probably means I'd prefer the full "mutable" keyword instead of "mut" or "var". Easy enough to change the name of a keyword in retrospect though, the important part is making the distinction at all.

[nikomatsakis]

Personally, I disagree with all this mutable bashing. I would prefer
mutability to be explicit but not painful. I am indifferent as to var
vs mut but a 3-letter keyword makes sense, so that it lines up well
with let.

[kud1ing]

let x; var y;

... even though i understand the proposal, i think i'd have to make a significant effort to come to the mental conclusion "x and y are both variables, var declares a mutable variable".

let x; mut y;
is probably easier to mentally process.

What would you think about having both let mutable x; and mut x;?

The first serves consistency with other uses of "mutable", the second would serve the lazy.
I think i would use both.

[nikomatsakis]

I've been thinking this over and I think I've developed a reasonably strong preference for:

let x = 5; // immutable
let mut x = 10; // mutable

This dovetails nicely with @mut 5.

[marijnh]

I've been thinking that {var x: int, var y: int} would look very strange. So I think mut is better, an let mut looks good to me.

[graydon]

Agreed. Consensus? :)

[brson]

Yes.

[nikomatsakis]

Fixed in dc07280