[rust-dev] On Copy = POD

Nick Cameron lists at ncameron.org
Sat Jun 21 02:10:35 PDT 2014


I guess I forgot that C++ ref counted pointers (pre-11) generally have a
move version of the type. Thanks for pointing that out.

I agree it would be odd to copy that design (Rc/RcTemp) in a language which
has move semantics by default. I wonder if we could come up with _some_
design that would be better than the current one. My reasoning is that
copy-with-increment is the (overwhelmingly) common case for ref-counted
pointers and so should be easier/prettier than the less common case
(moving). One could argue that the more efficient case (moving) should be
prettier and I think that is valid. I'm not sure how to square the two
arguments. I do think this deserves more thought than just accepting the
current (`.clone()`) situation - I think it is very un-ergonimic. Having
two types rather than two copying mechanisms seems more preferable to me,
but I hope there is a better solution.


On Sat, Jun 21, 2014 at 6:21 PM, Cameron Zwarich <zwarich at mozilla.com>
wrote:

> 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:
>
> https://www.webkit.org/coding/RefPtr.html
>
> 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.
>
> Cameron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140621/c1e2f820/attachment.html>


More information about the Rust-dev mailing list