[rust-dev] On Copy = POD

Cameron Zwarich zwarich at mozilla.com
Fri Jun 20 23:21:44 PDT 2014

On Jun 20, 2014, at 11:06 PM, Nick Cameron <lists at ncameron.org> wrote:

> zwarich: I haven't thought this through to a great extent, and I don't think here is the right place to plan the API. But, you ought to still have control over whether an Rc pointer is copied or referenced. If you have an Rc<T> object and pass it to a function which takes an Rc<T>, it is copied, if it takes a &Rc<T> or a &T then it references (in the latter case with an autoderef-ref). If the function is parametric over U and takes a &U, then we instantiate U with either Rc<T> or T (in either case it would be passed by ref without an increment, deciding which is not changed by having a copy constructor). If the function takes a U literal, then U must be instantiated with Rc<T>. So, you still get to control whether you reference with an increment or not.
> I think if Rc is copy, then it is always copied. I would not expect it to ever move. I don't think that is untenable, performance wise, after all it is what everyone is currently doing in C++. I agree the second option seems unpredictable and thus less pleasant.

Copying on every single transfer of a ref-counted smart pointer is definitely *not* what everyone is doing in C++. In C++11, move constructors were added, partially to enable smart pointers to behave sanely and eliminate extra copies in this fashion (albeit in some cases requiring explicit moves rather than implicit ones like in Rust).

Before that, it was possible to encode this idiom using a separate smart pointer for the expiring value. WebKit relies on (or relied on, before C++11) a scheme like this for adequate performance:


In theory, you could encode such a scheme into this “always copy on clone" version of Rust, where Rc would always copy, and RcTemp wouldn’t even implement clone, and would only be moveable and convertible back to an Rc. However, it seems strange to go out of your way to encode a bad version of move semantics back into a language that has native move semantics.


More information about the Rust-dev mailing list