Sorry to parachute in to the conversation (long time lurker) but just to
add to the statistics, the Scala standard library and compiler has
11875:54575 ratio of mutable (var) vs immutable (val) declarations, so it
seems to match pretty well with the numbers you guys are seeing in the rust
libraries.
On Thu, Jan 30, 2014 at 12:18 PM, Samuel Williams
space.ship.travel...@gmail.com wrote:
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 jfa...@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.travel...@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.travel...@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 ke...@sb.org wrote:
On Jan 29, 2014, at 6:43 PM, Brian Anderson bander...@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@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
