Add saturating_abs and saturating_neg

[t-rapp]

It would be great to have saturating_abs and saturating_neg functions for signed integer types. The current work-around is using a pattern like checked_$opr().unwrap_or($typ::max_value()) but having explicit functions would lift the corner-case knowledge "burden" from the user.

[hellow554]

What do you expect them to return? Just 0 for the two values that can't be expressed? IMHO you should prefer the check_$opr instead and explicitly handle that.

[t-rapp]

The abs and neg functions both have a corner case when the negative minimum value is used (e.g. -128 for type i8). The result cannot be represented within the bounds of the output type.

The saturating_abs / saturating_neg variants shall return a best-effort value (like 127 in case of -128 i8 input), similar to the existing saturating_add/sub/mul/pow functions.

assert_eq!(127i8.saturating_abs(), 127);
assert_eq!(-127i8.saturating_abs(), 127);
assert_eq!(-128i8.saturating_abs(), 127);

assert_eq!(127i8.saturating_neg(), -127);
assert_eq!(-127i8.saturating_neg(), 127);
assert_eq!(-128i8.saturating_neg(), 127);

[scottmcm]

These seems reasonable. I'd suggest just making a PR with them unstable and seeing what libs says.

By using 0.saturating_sub(x) they'll automatically get the new saturating implementation, too, which should be better for optimization and codegen than the checked_ approach.

[t-rapp]

Haven't done a PR for Rust yet so will take a look at the contribution guidelines and try to get along.

[jhpratt]

What's holding up stabilization on this? It seems relatively simple.

[t-rapp]

In my opinion there is nothing specific holding this up from being stabilized. Initially I wanted to give it some time for others to comment, then forgot about. Added a PR for stabilization now.