[rust-dev] On Copy = POD

Nick Cameron lists at ncameron.org
Fri Jun 20 20:49:27 PDT 2014

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>

> 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/ea46a373/attachment.html>

More information about the Rust-dev mailing list