Add saturating_abs and saturating_neg #59983

Activity

1. hellow554 commented on Apr 15, 2019

   

   hellow554

   on Apr 15, 2019

   Contributor

   More actions

   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.
2. jonas-schievink

   added

   C-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.

   T-libs-api[DEPRECATED; DO NOT USE][DEPRECATED; DO NOT USE]

   on Apr 15, 2019
3. t-rapp commented on Apr 15, 2019

   

   t-rapp

   on Apr 15, 2019

   ContributorAuthor

   More actions

   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);
   
4. scottmcm commented on Apr 16, 2019

   

   scottmcm

   on Apr 16, 2019

   Member

   More actions

   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.
5. t-rapp commented on Apr 16, 2019

   

   t-rapp

   on Apr 16, 2019

   ContributorAuthor

   More actions

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

   added a commit that references this issue on Apr 25, 2019

   Auto merge of #60192 - t-rapp:tr-saturating-funcs, r=alexcrichton

   ...

   c32171b
7. JohnTitor

   added

   B-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.

   C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFC

   and removed

   C-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.

   on Feb 28, 2020
8. jhpratt commented on May 1, 2020

   

   jhpratt

   on May 1, 2020

   Member

   More actions

   What's holding up stabilization on this? It seems relatively simple.
9. t-rapp commented on May 5, 2020

   

   t-rapp

   on May 5, 2020

   ContributorAuthor

   More actions

   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.

   👍React with 👍2Reacted by Jacob Pratt and Nameless Fellow
10. Dylan-DPC-zz

    added a commit that references this issue on May 19, 2020

    Rollup merge of rust-lang#71886 - t-rapp:tr-saturating-funcs, r=dtolnay

    ...

    This issue will close once commit 4c48f5a is merged into the 'master' branch.

    4c48f5a
11. bors

    closed this as completedin f99344aon May 19, 2020