Ahh, I guess I missed that rvalues of "moved" types are also moved when used as parameters. Yes, that throws a wrench into my reasoning. But this sucks! 95% of the time I don't want a function to take ownership of it's arguments. I understand that this was done for consistency with local assignments, but this adds so much line noise!
On Thu, Apr 4, 2013 at 4:13 PM, Daniel Micay <danielmi...@gmail.com> wrote: > On Thu, Apr 4, 2013 at 6:05 PM, Vadim <vadi...@gmail.com> wrote: > > What's so confusing about this? I agree that parameter modes had too > many > > options to think about, but this should be mostly transparent to the > user. > > Perhaps to the programmer semantics should stay the same as if parameter > was > > truly passed by value (i.e. no de-referencing needed). The difference > > would be on the calling convention level. > > > > The semantics between pass-by-value and pass-by-reference aren't the > same, because pass-by-value is a move of ownership for anything with a > destructor and borrowing a pointer has to freeze the object. > > For example, these function signatures on the Map trait express that > only insertion actually requires taking ownership of a value, which > allows to work with types that are non-cloneable/non-copyable: > > fn find(&self, key: &K) -> Option<&'self V>; > fn find_mut(&mut self, key: &K) -> Option<&'self mut V>; > fn insert(&mut self, key: K, value: V) -> bool; > fn remove(&mut self, key: &K) -> bool; > > In a lot of cases like this, & really means taking a parameter without > taking ownership and could in theory be optimized to a by-value > parameter for small objects. However, it would still need to act as an > immutable reference (freezing, inability to move out of it, lifetimes) > and it wouldn't have a semantic impact beyond adding complexity, just > a potential performance one for non-inlined functions. I don't think > it would really work out without adding a first-class > non-owning-immutable-thing-that-acts-like-a-pointer :P. >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
