Tracking Issue for const stability of unsigned bigint helpers #152015
Description
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.