[rust-dev] Integer overflow, round -2147483648
danielmicay at gmail.com
Wed Jun 18 13:19:24 PDT 2014
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> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Rust-dev