[rust-dev] Integer overflow, round -2147483648

Gábor Lehel 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>
wrote:

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

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
> https://mail.mozilla.org/listinfo/rust-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140620/5b56927e/attachment.html>


More information about the Rust-dev mailing list