[rust-dev] Integer overflow, round -2147483648

Jerry Morrison jhm456 at gmail.com
Wed Jun 25 14:28:44 PDT 2014


On Tue, Jun 24, 2014 at 6:06 PM, Vadim Chugunov <vadimcn at gmail.com> wrote:
>
> On Tue, Jun 24, 2014 at 5:41 PM, Daniel Micay <danielmicay at gmail.com>
>> wrote:
>>
>>> On 24/06/14 08:39 PM, Vadim Chugunov wrote:
>>> > I mostly agree, though  for #1, I think that new int types would be
>>> more
>>> > appropriate.   A set of special operators seems like an overkill for a
>>> > relatively infrequently used functionality.  Annotations are too broad
>>> > (what if I need to do both wrapping and non-wrapping calculations in
>>> the
>>> > same scope?).
>>>
>>> Introducing new types would make the language more painful to use, and
>>> it would be difficult to determine the correct types to use at API
>>> boundaries. It would be a large backwards compatibility hazard among
>>> other issues, and would introduce performance overhead due to issues
>>> like `&[u32]` and `&[u32c]` being different types.
>>
>>
> Easy: don't use normal ints in the API, Cast to wrapping ints when
> needed.    I don't expect the slice scenario to come up often, but if it
> does, these slice types can be transmuted into each other.
>

I'm hoping for illumination on that last point from someone who understands
the type system. If, say, u32w subtypes u32, then a u32w collection would
not be assignable to/from a u32 collection. It's the
covariant/contravariant mess. [Mathematicians don't pick understandable
names like "visitor pattern."]

-- 
   Jerry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140625/b8f14751/attachment.html>


More information about the Rust-dev mailing list