Widen the result of widening_mul.

[bjoernager]

Tracking issue: #152016

This PR implements #152016 (comment), which mandates that widening_mul return a single, scalar value rather than a low/high tuple.

Consequently, this method is removed from u128 and i128 as they are the widest integral types. It has also been removed from usize and isize due to portability concerns.

Existing widening_mul usage has been replaced by equivalent calls to carrying_mul (which is logically identical to the old behaviour.) Existing – generic – non-doc tests have been removed.

Public API

impl u8 {
    pub const fn widening_mul(self, rhs: Self) -> u16;
}

impl u16 {
    pub const fn widening_mul(self, rhs: Self) -> u32;
}

impl u32 {
    pub const fn widening_mul(self, rhs: Self) -> u64;
}

impl u64 {
    pub const fn widening_mul(self, rhs: Self) -> u128;
}

impl i8 {
    pub const fn widening_mul(self, rhs: Self) -> i16;
}

impl i16 {
    pub const fn widening_mul(self, rhs: Self) -> i32;
}

impl i32 {
    pub const fn widening_mul(self, rhs: Self) -> i64;
}

impl i64 {
    pub const fn widening_mul(self, rhs: Self) -> i128;
}

[rustbot]

Some changes occurred in integer formatting

cc @tgross35

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @scottmcm, libs
• @scottmcm, libs expanded to 8 candidates

[bjoernager]

@rustbot label +T-libs-api -T-libs

r? libs-api

[programmerjake]

IMO we need generic integers (which lets us have u<256>/i<256>) in order to support widening_mul on usize/isize/u128/i128 since Rust allows usize/isize to be 128-bit.

[bjoernager]

I suppose we could just let those implementation remain unstable. Or should we outright remove them as well?

[programmerjake]

I suppose we could just let those implementation remain unstable. Or should we outright remove them as well?

I think we should remove them unless we get a usizex2 type or something. Rust generally avoids having things that change type depending on the pointer size.

[clarfonthey]

Yeah, I thought I had replied to this, but apparently not. Definitely, I feel like usize and isize should not implement this method and people should be used to use carrying_mul instead with a carry of zero. We already have an efficient way of doing this; it's just that the widening_mul primitive is particularly useful as an API, although only when it actually makes sense to say "an integer twice as wide."

[tgross35]

r? libs

@rustbot label +T-libs-api -T-libs

r? libs-api

libs-api already discussed this change, somebody from libs can check it

[rustbot]

The review request libs corresponds to 7 reviewer(s).
However, none of them are available for a review at this time.
Use r? to specify someone else to assign.

[tgross35]

r? tgross35

[tgross35]

Actually r? clarfonthey since you've looked at this already, feel free to kick it back if you don't have the time.

[clarfonthey]

Looks good to me.

@bors r+ rollup

[rust-bors]

📌 Commit 0a07235 has been approved by clarfonthey

It is now in the queue for this repository.