4 ms·
I'm no Rust expert, but it would be ok if you would do borrows there. let x = compute_x(); f(&x); g(&x); Otherwise you have moves there. Now it depends
by hawski 4y ago
I'm no Rust expert, but it would be ok if you would do borrows there.
let x = compute_x();
f(&x);
g(&x);
Otherwise you have moves there. Now it depends on the API, it may want the value and not the reference (a borrow).
- deleted 4y ago[deleted]
- topaz0 4y agoI see. Is it not common practice for functions to expect references when they can (i.e. when they don't need to modify the argument)?
- tialaramex 4y agoNot just when they don't need to modify the argument, when they don't need to consume it. The way these parameters are written takes ownership of x, it's gone, not just modified. For a non-trivial object (which apparently x is), you would always prefer to write &x (immutable reference to x) or at least &mut x (mutable reference, not applicable here because x is not defined as a mutable thing). So apparently these functions intend to consume x. That's not common but there are a reasonable number of Rust APIs which consume larger things on purpose.
- topaz0 4y ago> So apparently these functions intend to consume x. I guess in that case I don't really get the complaint. If there's a good reason for f or g to consume x, I would think I would always want the copy to be explicit. But I could still be missing some subtlety I guess.
- tialaramex 4y agoYeah, it feels reasonable to me, but I'm a happy Rust programmer, perhaps if you're mostly working in functional languages this feels very wrong, I would not know.
- steveklabnik 4y agoRust can be like this, because it tends to expose a lot of information, and not everyone cares about every type of information.
- ismailmaj 4y agoThe common scenario for f and g to consume x is that x is a smart pointer type e.g. Rc/Arc. to make it clear that the clone is "cheap", some Rust developer prefer using `Arc::Clone(&x)` over `x.clone()`.