If the function is not going to mutate it, I don't really care if it's by-ref or by-value. That's why I said "const T&", not "T&". Well, except for the case when a function caches a reference to something which I later mutate. But borrow checking will prevent that.
I would also be totally fine with letting the compiler figure out how immutable arguments are passed (based on data type size, existence of destructors, and whatnot). This might not be the best idea for binary compatibility of public APIs, but I don't see why it can't be done with crate-private functions. On Tue, Nov 19, 2013 at 5:07 PM, Ziad Hatahet <[email protected]> wrote: > > Personally I would prefer if & in Rust worked similar to const T& in c++ > > In that case, you would not be able to tell whether a function argument > was passed by value or by reference. I actually like this feature about > Rust (C# has it too with the `ref` keyword). > > -- > Ziad > > > On Tue, Nov 19, 2013 at 4:54 PM, Vadim <[email protected]> wrote: > >> So why did Rust adopt auto-moving instead of explicit moving? If the >> second example had to be written as foo(move a) there would be no >> confusion. The and the third example should arguably be sort(mut >> a.as_mut_slice()). >> >> Personally I would prefer if & in Rust worked similar to const T& in c++ >> (i.e. for most intents and purposes you can treat a reference as a value), >> otherwise half of the arguments on each function call will have to be >> adorned with ampersands. >> >> Can we have it such that foo(a) would be guaranteed to not mutate or move >> a and require "mut" or "move" prefix otherwise? >> >> >> _______________________________________________ >> 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
