-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking Issue for saturating_div
#89381
Comments
@rfcbot merge |
Team member @yaahc has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
Stabilize feature `saturating_div` for rust 1.58.0 The tracking issue is rust-lang#89381 This seems like a reasonable simple change(?). The feature `saturating_div` was added as part of the ongoing effort to implement a `Saturating` integer type (see rust-lang#87921). The implementation has been discussed [here](rust-lang#87921 (comment)) and [here](rust-lang#87921 (comment)). It extends the list of saturating operations on integer types (like `saturating_add`, `saturating_sub`, `saturating_mul`, ...) by the function `fn saturating_div(self, rhs: Self) -> Self`. The stabilization of the feature `saturating_int_impl` (for the `Saturating` type) needs to have this stabilized first. Closes rust-lang#89381
I'm just curious: why was this feature stabilized so soon after being added? IIRC, usually features wait for at least a couple months before being stabilized. |
AFAIK it has been a couple months, I think that it was just missing the tracking issue because they split this out as a partial stabilization from #87920. The original PR adding it landed in late august, #87921, so it was a bit on the fast side but AFAIK we don't have any rule about how long things should remain on nightly before they're eligible for stabilization. Maybe we should? In this case I don't expect it will be a problem, this one seems pretty non-controversial, but I'm curious what the rest of @rust-lang/libs-api thinks. |
IIRC, |
The feature gate for the issue is
#![feature(saturating_div)]
.About tracking issues
This tracking issue tracks the progress of the
saturating_div
feature, which shall provide a saturating division for integer types. It is part of the ongoing effort to stabilize theSaturating
type #87920Unresolved Questions
None. The implementation has been discussed here and here.
Steps
saturating_div
(Stabilize featuresaturating_div
for rust 1.58.0 #88624)Implementation history
fn saturating_div
andfeature(saturating_div)
The text was updated successfully, but these errors were encountered: