[rust-dev] On Copy = POD

Benjamin Striegel ben.striegel at gmail.com
Sat Jun 21 09:00:35 PDT 2014


> I don't think that is untenable, performance wise, after all it is what
everyone is currently doing in C++.

We have already made several decisions that will disadvantage us with
regard to C++. When we have the opportunity to do better, performance-wise,
than C++, we must seize it in order to maintain performance parity overall.


On Sat, Jun 21, 2014 at 2:06 AM, Nick Cameron <lists at ncameron.org> 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.
>
> Cheers, Nick
>
>
> On Sat, Jun 21, 2014 at 4:05 PM, Cameron Zwarich <zwarich at mozilla.com>
> wrote:
>
>> 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/bb2bac58/attachment.html>


More information about the Rust-dev mailing list