Tracking issue for `core::ops::*<T>` on `Saturating<T>` / `Wrapping<T>` type

[kellerkindt]

Relevant RFC "928" (rust-lang/rfcs#928).

• Tracking Issue for Saturating type #87920
• Tracking issue for integer methods for Wrapping #32463

Public API

The Wrapping and Saturating types enforce that a certain behaviour for all operations on the underlying integer is performed - .wrapping_* or .saturating_*. When doing the "simplified" operations, .add always becomes .wrapping_add or .saturating_add, .sub always becomes .wrapping_sub / .saturating_sub and so on.

The fundamental ideas seem to be:

1. Never perform the an integer operation with the wrong behaviour by forgetting to write .wrapping_* or .saturating_*
2. Reduce boiler-plate code / text by being able to omit writing .wrapping_* or .saturating_*

But number 2 seems to fall short in reality. The traits in core::ops:: are only implemented for Wrapping and Saturating where the other type is Wrapping or Saturating as well (impl core::ops::*<Wrapping<T>> for Wrapping<T>¹). So, instead of writing a integer addition like this:

    let mut value = 17u8;
    // ...
    value += 8;
    value *= 7;
    // ...
    let other: u8 = value / 3;

for Wrapping and Saturating types, it looks likes this:

    let mut value = Wrapping(17u8);
    // ...
    value += Wrapping(8);
    value *= Wrapping(7);
    // ...
    let other: Wrapping<u8> = value / Wrapping(3);

This introduces the need for additional mentions of Wrapping / Saturating in every code location where an integer operation is performed - and in my opinion, adds unnecessary noise to the code. In my opinion, having the integer being wrapped in either Wrapping or Saturating in the declaration / initialization should be all that is needed.

I propose that - in addition to impl core::ops::*<Wrapping<T>> for Wrapping<T>¹ - the integer operations are also implemented using the raw integer type itself (impl core::ops::*<T> for Wrapping<T>¹), and therefore the following is being made possible:

    let mut value = Wrapping(17u8);
    // ...
    value += 8;
    value *= 7;
    // ...
    let other: Wrapping<u8> = value / 3;

¹ as well as for Saturating

Steps / History

• Decide on wrapping integer (Integer overflow RFC needs more wrapper types rfcs#928)
• Implement basic Wrapping type Tracking issue for integer methods for Wrapping #32463
  • Stabilize it
• Implement basic Saturating type Tracking Issue for Saturating type #87920
  • Stabilize it (WIP)
• Add raw integer operations
  • on Wrapping TBD
  • on Saturating Tracking Issue for saturating_int_assign_impl #92354
• Stabilize raw integer operations
  • on Wrapping
  • on Saturating

Unresolved Questions

• RFC vs PR?.
  Following "The overarching philosophy is: do whatever is easiest", I created this PR because the underlying types already exist, and it "only" proposes additional trait impls. Or does this change need a proper RFC?