[rust-dev] Integer overflow, round -2147483648
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>
>>> On 24/06/14 08:39 PM, Vadim Chugunov wrote:
>>> > I mostly agree, though for #1, I think that new int types would be
>>> > 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
>>> > 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."]
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rust-dev