On Wed, Jun 18, 2014 at 10:19 PM, Daniel Micay <danielmi...@gmail.com> wrote:
> 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. > I agree. Sorry if I wasn't clear: I wasn't supposing we might bend the rules for `Gc<T>`, but that `Gc<T>` might fit them. > > > _______________________________________________ > 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
