Hacker News Reader

Comment by yeslibertarian | Hacker News Reader

A good rule is to let the caller decide. If input parameters are by-reference and the caller wants to make them by-reference, congrats, no problem. If caller wants the parameters to by a copy, they can create a clone and pass a reference. But if you impose the input parameters to by copy, there's no way back.

View on HN

Although your point is sort-of true, but I don't really see how it's valid here. The author is talking about the performance implications of the two approaches in situations where the function parameters are not mutated. Suggesting that user "makes the choice" here by taking defensive copies for themselves will probably (but who knows what the optimisers will do - they might just elide it) make performance worse. It's not something end users will think to do, anyway, at least not in the name of performance.

Regardless, I want a library author to help me fall into the pit of performance success, not expect me to do it all for myself.

In the case of Rust it would typically be an immutable reference (or else passing by value wouldn't be an alternative). So the caller would have no reason to make a copy.

In Rust (end even C++ afaik) it usually makes more sense to let the callee decide. Does it need to own the value? -> Call by value. Does it only need to inspect or (visibly) mutate the value during the function call? -> Call by reference (modulo optimization concerns).

Functions can also be generic over references vs. move/copy semantics, e.g.:

    fn foo<T>(frob: T) where T: Borrow<Frob> {
      // Do something with frob.borrow()
    }

Due to monomorpization, foo is specialized for moves/clones when called as foo(frob) where frob is a value type or for borrows when called as foo(&frob). Similarly, you can use Clone, ToOwned or even Into for going in the opposite direction.

Whether such functions are good taste in general is debatable ;).

You want AsRef, not Borrow, unless you need the additional guarantees that Borrow provides (identical comparisons and hashing).

Reply on news.ycombinator.com