[rust-dev] On Copy = POD

Benjamin Striegel ben.striegel at gmail.com
Fri Jun 20 21:04:23 PDT 2014


> I think having copy constructors is the only way to get rid of `.clone()`
all over the place when using` Rc`.

I find making `.clone()` explicit to be a valuable feature, and I bet I'm
not the only one. Its absence guarantees that the pointer is being moved
and no refcount is being bumped.

It's one thing if the inclusion of copy constructors allows code to be more
generic. But muddying program behavior just to make the source code
prettier is a poor tradeoff for a systems language.


On Fri, Jun 20, 2014 at 11: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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140621/8fa8e4d1/attachment.html>


More information about the Rust-dev mailing list