[rust-dev] Not-quite-proposal about & sigils

Vadim vadimcn at gmail.com
Thu Apr 4 19:56:24 PDT 2013

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 <danielmicay at gmail.com> wrote:

> On Thu, Apr 4, 2013 at 6:05 PM, Vadim <vadimcn at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20130404/36291d01/attachment.html>

More information about the Rust-dev mailing list