Change:
} } <ins> /// Computes the absolute difference between `self` and `other`. /// /// This function always returns the correct answer without overflow or /// panics by returning an unsigned integer. /// /// # Examples /// /// Basic usage: /// /// ``` /// #![feature(int_abs_diff)] #[doc = concat!("assert_eq!(100", stringify!($SelfT), ".abs_diff(80), 20", stringify!($UnsignedT), ");")] #[doc = concat!("assert_eq!(100", stringify!($SelfT), ".abs_diff(110), 10", stringify!($UnsignedT), ");")] #[doc = concat!("assert_eq!((-100", stringify!($SelfT), ").abs_diff(80), 180", stringify!($UnsignedT), ");")] #[doc = concat!("assert_eq!((-100", stringify!($SelfT), ").abs_diff(-120), 20", stringify!($UnsignedT), ");")] #[doc = concat!("assert_eq!(", stringify!($SelfT), "::MIN.abs_diff(", stringify!($SelfT), "::MAX), ", stringify!($UnsignedT), "::MAX);")] /// ``` #[unstable(feature = "int_abs_diff", issue = "89492")] #[inline] pub const fn abs_diff(self, other: Self) -> $UnsignedT { if self < other { // Converting a non-negative x from signed to unsigned by using // `x as U` is left unchanged, but a negative x is converted // to value x + 2^N. Thus if `s` and `o` are binary variables // respectively indicating whether `self` and `other` are // negative, we are computing the mathematical value: // //    (other + o*2^N) - (self + s*2^N)    mod  2^N //    other - self + (o-s)*2^N            mod  2^N //    other - self                        mod  2^N // // Finally, taking the mod 2^N of the mathematical value of // `other - self` does not change it as it already is // in the range [0, 2^N). (other as $UnsignedT).wrapping_sub(self as $UnsignedT) } else { (self as $UnsignedT).wrapping_sub(other as $UnsignedT) } } </ins> /// Returns a number representing sign of `self`. /// ///  - `0` if the number is zero

Discussion:
See discussion in
I suggest not calling it due to the confusion created by the (terribly misnamed) , whose tortured legacy continues to this day in .
perhaps?
abs_difference ?
What do you think about adding: instead of doing it on just the unsigned integer types?
is a good name, I think, as it is the mathematical term for . I dislike above generalization, as what it does is unrelated with the name of the function in most cases (the first thing that comes to mind is that something called an « absolute difference » should be a non-negative real number).
The term seems too generic from the standpoint of a mathematical motivation, it is also used in the context of very different metric spaces than the normed space induced by the L1-norm. I think 'absolute difference' hits the nail on the head and with the given prior art of abbreviations that would make my clear favorite. Similar to , and other functions it doesn't seem necessary to add it in another way than as a method.
Until that happens, I've found the easiest way to do this is:
If no one has any objections I can make a pull request implementing the following functions: where for unsigned types the implementation would be and for signed types Especially the latter is a useful contribution as it is somewhat non-trivial and tricky to write correctly as a user, if you are not intimately familiar with two's complement.
Just sharing some experience from the wild: I have code of the form where I check before I call , because I need a different code path for that case versus the case. However, that check is repeated within the impl, so I was wondering whether I should write out the manually. But, it when the compiler decides to inline , it is smart enough to collapse the statements into one. So I think using vanilla is fine for my case. Thanks for adding it!