Wow! the community here is more active than I had anticipated! I have read responses from you guys. The community's main concern is that pass-by-value should be the default desired behavior. Thus explicitness here helps in reasoning program flow. However, with deep-immutable variables, it should not matter. If so, we should require the ampersand sigil only for mutable stack variables.
Also, I am not sure whether you guys have looked at Copy-On-Write implicit-shared mechanism of the core Qt classes. I think they are amazing and helps explain why immutable variables in practice can be passed as arguments without additional syntax. I think my first point is minor. If the language designer feels that we should keep the existing way of borrowing local stack variables at the caller site, then it shall be. A future IDE could hint the sigil during auto-completion. I see the merits of having the ampersand, but the tutorial should just explain this as "converting a stack-variable into a box that can be borrowed by others", rather than using the C paradigm of passing a pointer or address on the stack. This would make the idea of boxes consistent to beginners. Heri Sent from my iPhone On 8 Apr, 2013, at 11:58 AM, Tim Chevalier <[email protected]> wrote: > On Sun, Apr 7, 2013 at 3:01 PM, Heri Sim <[email protected]> wrote: >> Hi guys, I am new here. Just found out about this project today, and >> read up a lot on its history and purpose. >> >> >> There are 3 gripes I have about Rust, after comparing some good stuff >> in Go-lang. http://tour.golang.org >> >> >> 1st, dereferencing should be automatic everywhere. >> Running a pattern match on borrowed boxes should NOT require an asterisk (*). >> Passing in a stack-local variable to a function or closure (that >> requires arguments to be passed by reference), should not require the >> ampersand (&) in the caller. Why can't the compiler figure this out? > > We tried the second idea before Rust 0.4; it was called "modes". It > was confusing and inconsistent. > >> >> In go-lang, all these things are just more invisible, which makes the >> learning curve so much easier. I understand people coming from C would >> prefer these memory-management signets explicit, but really they have >> little need to be so verbose in many cases, and should be optional or >> by-default instead, so that things just-work. (Just-like how custom >> borrow lifetimes are optional, and defaults well in most cases.) > > Feel free to fork Rust and implement the inference you're describing > :-) This part of the language has been subject to a ton of work and > length discussion. As with so many aspects of language design and > implementation, it's more subtle than it seems. > > BTW, for harmonious discussions on this mailing list, it's best to > indicate what is your opinion and what you believe is indisputable > fact. The Rust code of conduct applies here: > https://github.com/mozilla/rust/wiki/Note-development-policy -- > specifically, "Respect that people have differences of opinion and > that every design or implementation choice carries a trade-off and > numerous costs. There is seldom a right answer." > > Cheers, > Tim > > -- > Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt > "Too much to carry, too much to let go > Time goes fast, learning goes slow." -- Bruce Cockburn _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
