On 18/06/14 03:40 PM, comex wrote: > On Wed, Jun 18, 2014 at 1:08 PM, Gábor Lehel <glaebho...@gmail.com> wrote: >> To partially address this, once we have tracing GC, and if we manage to make >> `Gc<T>: Copy`, we should add unbounded `Integer` (as in Haskell) and >> `Natural` types which internally use `Gc`, and so are also `Copy`. (In >> exchange, they wouldn't be `Send`, but that's far less pervasive.) > > Wait, what? Since when is sharing data between threads an uncommon use case?
Data remaining local to the thread it was allocated in is the common case. That doesn't mean that sending dynamic allocations to other tasks or sharing dynamic allocations is bad. `Rc<T>` is inherently local to a thread, so it might as well be using an allocator leveraging that. > (Personally I think this more points to the unwieldiness of typing > .clone() for cheap and potentially frequent clones like Rc...) Either way, it doesn't make sense to make a special case for `Gc<T>`. If `copy_nonoverlapping_memory` isn't enough to move it somewhere, then it's not `Copy`. A special-case shouldn't be arbitrarily created for it without providing the same thing for user-defined types. That's exactly the kind of poor design that Rust has been fleeing from.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
