Integer overflow RFC needs more wrapper types

[pnkfelix]

This is an issue in need of a PR to modify RFC #560 (text)

During the course of my work attempting to land the integer overflow checking PRs (see rust-lang/rust#22532), I identified some simple types that we should consider adding to the stdlib.

1. The RFC documents WrappingOps Wrapping<N>, which just marks the type as following the usual arithmetic modulo bitwidth rules. (So this is sort of built-in already, not a new change.)
2. In addition, I added OverflowingOps, which provides methods for e.g. overflowing_add(self, Self) -> (Self, bool), where the returned boolean is a flag indicating whether overflow occurred. This was quite useful for composing certain functions where knowledge of overflow was needed. (i am not sure if a Overflowing<N> trait is warranted.)
3. We probably also want SaturatingOps and Saturating<N>. (I think we already have the methods for the former; so that is just a question of whether the ops need their its own trait. But I think `Saturating is justified either way.)
4. I think we may want some form of support for impl Add<N> for Result<N, Overflow>> where the result type is Result<N, Overflow> (and Overflow is a zero-sized struct). At least, I think this would enable patterns of composition like let value: N = try!(a + b - c + d);
   • ---- (adding more ideas below this line) ----
5. Atomic numeric types probably need to be addressed in some way as well; see discussion here: Implement arithmetic overflow changes rust#20795 (comment)

[pnkfelix]

(also, nikomatsakis mentioned to me earlier today that it would be cool if we could teach LLVM to be smart about optimizing try!(a + b - c + d) for Result<N, Overflow>, e.g. have it use the knowledge, (when applicable) that an overflow condition bit will remain set to "on" until reset, and thus be able to do all of the arithmetic without any conditionals until the end of the try!.)

[Gankra]

What is the value of the Self if the overflow value is true? Wrapped overflow? Unspecified?

[pnkfelix]

@gankro oh; its been useful to me for it to denote wrapped overflow.

[pnkfelix]

I am now wondering, for OverflowingOps, presumably it would have analogous fn overflowing_div and fn overflowing_rem ... but ... should fn overflowing_rem actually ever return true for the overflow bit? As pointed out by bill-myers, mathematically no overflow is occurring when one computes ((T::MIN % -1) mod 2^N) == 0

Update: see also #964