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