[mkishi]

> The preferred action is to allocate on the caller's heap and pass a mutable reference down to the callee.

Care to link/elaborate this? I thought the recommendation was to return by value in this case -- making it easy for the caller to decide where to store the value. The move semantics would then optimize the copy away, so you end up using either the caller's stack or the heap, depending on how the call was made.

[steveklabnik]

You're correct.

[mkishi]

Actually, I got curious and tried it out. Turns out Rust didn't optimize the heap case: it used the caller's stack, and only then copied the value to the heap.

https://play.rust-lang.org/?code=%23!%5Bfeature(core)%5D%0A%...

[pcwalton]

Because it would change the semantics of the program. Where heap allocations happen is considered a side effect, and forcing a function to be inline(never) also makes it have unconstrained side effects (in some cases). Those side effects cannot be reordered.

[steveklabnik]

That's because of `Box::new`, I'd think. If you use the box keyword, you should get the placement new effect.

[mkishi]

Thank you! I thought the box keyword was simply a syntactic sugar -- I'm not that familiar with placement new, even in C++.

Note for the interested: the optimization works right now, even though the keyword is behind the box_syntax feature gate.

Updated test: https://play.rust-lang.org/?code=%23!%5Bfeature(core)%5D%0A%...