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 <li...@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.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

_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to