Tracking Issue for const stability of unsigned bigint helpers #152015

Feature gate: #![feature(bigint_helper_methods)] (for now)

This is a tracking issue for the const stability of the bigint helper methods added in 1.91.0.

Public API

impl uN {
    const fn carrying_add(self, rhs: uN, carry: bool) -> (uN, bool);
    const fn borrowing_sub(self, rhs: uN, borrow: bool) -> (uN, bool);
    const fn carrying_mul(self, rhs: uN, carry: uN) -> (uN, uN);
    const fn carrying_mul_add(self, rhs: uN, carry: uN, add: uN) -> (uN, uN);
}

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• Previous tracking issue Tracking Issue for bigint helper methods #85532
• Stabilization PR Partial-stabilize the basics from bigint_helper_methods #144494
• Final commenting period (FCP)

Notes

These were originally not stabilised as part of the original per @scottmcm:

I did not const-stabilize them in this PR because the fallbacks are using #[const_trait] plus there's two new intrinsics involved, so I didn't want to also open those cans of worms here. Given that both intrinsics have fallbacks, and thus don't do anything that can't already be expressed in existing Rust, const-stabilizing these should be straight-forward once the underlying machinery is allowed on stable. But that doesn't need to keep these from being usable at runtime in the mean time.

Note that at minimum, a T-lang FCP would be needed on a stabilization PR to accept the const-stabilization of those intrinsics. Additionally, we will probably be blocked on #[const_trait] being stable unless there's a blessing from at least a few folks involved to stabilize these methods regardless.

Unresolved Questions

• None yet.