Hi list, I’d like the fact “a = 10” or “mut a = 10” are shorter to write than “let a = 10” or “let mut a = 10”. On the other hand, I *really* appreciate the fact `grep -ri let src/ | grep (or -v) mut` will return me quickly where the variable declaration are. So in the end, I feel I can “pay”/suffer for 3 more characters to write (“let”) for the second hand benefits.
(notwithstanding other far more important/structural arguments already presented in this thread, that rationalise the fact “let/let mut” is a excellent choice anyhow :). my 2 cents of Rust beginner. — lem On 30 Jan 2014, at 08:32, Gaetan <[email protected]> wrote: > I like the fact that is more expensive to write let mut than let. So you > initialize mutable variable on purpose > > Le 30 janv. 2014 05:31, "Haoyi Li" <[email protected]> a écrit : > 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 > <[email protected]> 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 <[email protected]> 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 > <[email protected]> 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 <[email protected]> > 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 <[email protected]> wrote: > On Jan 29, 2014, at 6:43 PM, Brian Anderson <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > > > > > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > > > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
