[rust-dev] Integer overflow, round -2147483648
glaebhoerl at gmail.com
Fri Jun 20 13:56:17 PDT 2014
On Wed, Jun 18, 2014 at 10:19 PM, Daniel Micay <danielmicay at gmail.com>
> On 18/06/14 03:40 PM, comex wrote:
> > On Wed, Jun 18, 2014 at 1:08 PM, Gábor Lehel <glaebhoerl at gmail.com>
> >> To partially address this, once we have tracing GC, and if we manage to
> >> `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
> 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 at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rust-dev