[rust-dev] On Copy = POD

Nick Cameron lists at ncameron.org
Fri Jun 20 23:06:22 PDT 2014

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.

Cheers, Nick

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

> I sort of like being forced to use .clone() to clone a ref-counted value,
> since it makes the memory accesses and increment more explicit and forces
> you to think which functions actually need to take an Rc and which
> functions can simply take an &.
> Also, if Rc becomes implicitly copyable, then would it be copied rather
> than moved on every use, or would you move it on the last use? The former
> seems untenable for performance reasons, since removing unnecessary
> ref-count operations is important for performance. The latter seems
> unpredictable, since adding a second use of a value in a function would
> mean that new code is implicitly executed wherever the first use is.
> Cameron
> On Jun 20, 2014, at 8:49 PM, Nick Cameron <lists at ncameron.org> wrote:
> I think having copy constructors is the only way to get rid of `.clone()`
> all over the place when using` Rc`. That, to me, seems very important (in
> making smart pointers first class citizens of Rust, without this, I would
> rather go back to having @-pointers). The trouble is, I see incrementing a
> ref count as the upper bound on the work that should be done in a copy
> constructor and I see no way to enforce that.
> So, I guess +1 to spirit of the OP, but no solid proposal for how to do it.
> On Sat, Jun 21, 2014 at 8:00 AM, Benjamin Striegel <ben.striegel at gmail.com
> > wrote:
>> I'm not a fan of the idea of blessing certain types with a
>> compiler-defined whitelist. And if the choice is then between ugly code and
>> copy constructors, I'll take ugly code over surprising code.
>> On Fri, Jun 20, 2014 at 3:10 PM, Patrick Walton <pcwalton at mozilla.com>
>> wrote:
>>> On 6/20/14 12:07 PM, Paulo Sérgio Almeida wrote:]
>>>  Currently being Copy equates with being Pod. The more time passes and
>>>> the more code examples I see, it is amazing the amount of ugliness that
>>>> it causes. I wonder if there is a way out.
>>> Part of the problem is that a lot of library code assumes that Copy
>>> types can be copied by just moving bytes around. Having copy constructors
>>> would mean that this simplifying assumption would have to change. It's
>>> doable, I suppose, but having copy constructors would have a significant
>>> downside.
>>> Patrick
>>> _______________________________________________
>>> Rust-dev mailing list
>>> Rust-dev at mozilla.org
>>> https://mail.mozilla.org/listinfo/rust-dev
>> _______________________________________________
>> Rust-dev mailing list
>> Rust-dev at mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140621/5781ef21/attachment.html>

More information about the Rust-dev mailing list