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

Samuel Williams space.ship.traveller at gmail.com
Wed Jan 29 20:18:18 PST 2014


Jason, I haven't actually written any rust code (yet). I'm just commenting
based on reading other people's code - it was something I noticed in a few
examples - it might have been bad form (assuming that mutable data are the
"Wrong Thing"?). I brought it up because I wasn't sure if it was something
that had been considered. It made the code I was reading look a bit clunky
(which appears to be the desired result).


On 30 January 2014 17:07, Jason Fager <jfager at gmail.com> wrote:

> 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
>> > 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> wrote:
>>>
>>>> On Jan 29, 2014, at 6:43 PM, Brian Anderson <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
>>>> https://mail.mozilla.org/listinfo/rust-dev
>>>>
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140130/45b67f28/attachment-0001.html>


More information about the Rust-dev mailing list