[rust-dev] "let mut" <-> "var"

Jason Fager jfager at gmail.com
Wed Jan 29 20:07:44 PST 2014

You *should* get sick of writing 'let mut' all over the place, not just b/c
of the syntax but b/c you're using mutable variables "all over the place".
 Casual mutability kills maintainability.

Affordances matter.  I'm convinced that the reason Option.unwrap() is used
so frequently is b/c it's the shortest method name and requires the
fewest explicit decisions, and so is the easiest thing to reach for.  If it
were unwrap_or_fail("reason"), forcing you to both type more and to think
about a fail message, unwrap_or and unwrap_or_else wouldn't look as
difficult in comparison.  or and or_else would be even better, or
'do' syntax now that the keyword's free again.

Make the Right Thing the easy thing, and don't put effort into making the
Wrong Thing as easy or easier.

On Wednesday, January 29, 2014, Samuel Williams <
space.ship.traveller at gmail.com> wrote:

> I agree that it is syntactic salt and that the design is to discourage
> mutability. I actually appreciate that point as a programmer.
> w.r.t. this specific issue: I think what concerns me is that it is quite a
> high burden for new programmers (I teach COSC1xx courses to new students so
> I have some idea about the level of new programmers). For example, you need
> to know more detail about what is going on - new programmers would find
> that difficult as it is one more concept to overflow their heads.
> Adding "var" as a keyword identically maps to new programmer's
> expectations from JavaScript. Writing a program entirely using "var"
> wouldn't cause any problems right? But, could be optimised more
> (potentially) if using "let" for immutable parts.
> Anyway, I'm not convinced either way, I'm not sure I see the entire
> picture yet. But, if I was writing code, I'd certainly get sick of writing
> "let mut" over and over again - and looking at existing rust examples, that
> certainly seems like the norm..
> On 30 January 2014 15:59, Samuel Williams <space.ship.traveller at gmail.com<javascript:_e({}, 'cvml', 'space.ship.traveller at gmail.com');>
> > wrote:
>> I guess the main gain would be less typing of what seems to be a
>> reasonably common sequence, and the formalisation of a particular semantic
>> pattern which makes it easier to recognise the code when you visually
>> scanning it.
>> On 30 January 2014 15:50, Kevin Ballard <kevin at sb.org <javascript:_e({},
>> 'cvml', 'kevin at sb.org');>> wrote:
>>> On Jan 29, 2014, at 6:43 PM, Brian Anderson <banderson at mozilla.com<javascript:_e({}, 'cvml', 'banderson at mozilla.com');>>
>>> wrote:
>>> > On 01/29/2014 06:35 PM, Patrick Walton wrote:
>>> >> On 1/29/14 6:34 PM, Samuel Williams wrote:
>>> >>> Perhaps this has been considered already, but when I'm reading rust
>>> code
>>> >>> "let mut" just seems to stick out all over the place. Why not add a
>>> >>> "var" keyword that does the same thing? I think there are lots of
>>> good
>>> >>> and bad reasons to do this or not do it, but I just wanted to propose
>>> >>> the idea and see what other people are thinking.
>>> >>
>>> >> `let` takes a pattern. `mut` is a modifier on variables in a pattern.
>>> It is reasonable to write `let (x, mut y) = ...`, `let (mut x, y) = ...`,
>>> `let (mut x, mut y) = ...`, and so forth.
>>> >>
>>> >> Having a special "var" syntax would defeat this orthogonality.
>>> >
>>> > `var` could potentially just be special-case sugar for `let mut`.
>>> To what end? Users still need to know about `mut` for all the other uses
>>> of patterns. This would reserve a new keyword and appear to duplicate
>>> functionality for no gain.
>>> -Kevin
>>> _______________________________________________
>>> Rust-dev mailing list
>>> Rust-dev at mozilla.org <javascript:_e({}, 'cvml',
>>> 'Rust-dev at mozilla.org');>
>>> https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140129/b64dc8d8/attachment.html>

More information about the Rust-dev mailing list