Hacker News Reader

Comment by hawski | Hacker News Reader

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).

View on HN

I 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)?

Not 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.

> 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.

Rust can be like this, because it tends to expose a lot of information, and not everyone cares about every type of information.

The 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()`.

Yeah, 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.

Reply on news.ycombinator.com