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.strie...@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 <pcwal...@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@mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
