[rust-dev] On Copy = POD

Daniel Micay danielmicay at gmail.com
Fri Jun 20 23:14:23 PDT 2014

On 21/06/14 02:06 AM, Nick Cameron wrote:
> bstrie: you're right it is a trade off, but I don't agree that its not
> worth it. We're talking about non-atomic incrementing of an integer -
> that is pretty much the cheapest thing you can do on a processor (not
> free of course, since caching, etc., but still very cheap). I've
> programmed a lot in C++ with ref counted pointers and never had a
> problem remembering that there is a cost, and it makes using them
> pleasant. I found all the clone()s in Rust unpleasant, it really put me
> off using ref counting. The transition from using references to using Rc
> was particularly awful. Given that this is something C++ programmers
> coming to Rust will be used to using, I believe ergonomics is especially
> important.
> In this case I don't think we need to aim to be more 'bare metal' than
> C++. Transparent, ref counted pointers in C++ are popular and seem to
> work pretty well, although obviously not perfectly.
> 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.

It's a severe performance issue in C++11 with `std::shared_ptr` because
it uses atomic reference counting.

Even for `Rc<T>`, these writes cause significant issues for alias
analysis and end up causing many missed optimizations.

Rust needs a way to elide them, and with the `move` keyword gone that
means last use analysis or maintaining the current situation where Rust
always performs the same operation as C for passing, returning and
assignment (a shallow copy).

It will be much harder to write failure-safe code if basic operations
like assignment can fail.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140621/d171e34c/attachment.sig>

More information about the Rust-dev mailing list