Repository navigation
Tracking Issue for exact_div #139911
Description
Activity
How do these handle overflow (
iN::MIN / -1)?For the safe version this makes sense but for
unchecked_exact_divit’s not obvious to me that UB is the right choice. Having three distinct preconditions to check (no remainder, no division by zero, no overflow) is not great because it’s easy to forget one, especially the overflow edge case. Even for unsigned types, the precedent in stable Rust is handling division by zero viaimpl Div<NonZeroT> for Tinstead of an unsafe method that’s UB on zero RHS. This may be useful in this case as well. And overflow in signed division could panic even if the “no remainder” portion is unchecked under threat of UB.Just because the perma-unstable intrinsic works this way doesn’t mean it’s also the best option for a stable user-facing API. We also have an
unchecked_divintrinsic but as noted in my last comment, it’s not exposed as-is.Any other behavior would be surprising. You could argue that we don't need
unchecked_exact_divmethods similarly to how we don't haveunchecked_div, but there was an explicit interest in it during previous discussion. Personally, I think we should addunchecked_divmethods instead.I’m not here to argue about whether the functionality is needed, just point out that there’s other ways to expose it that may be better (easier to use correctly), at least for unsigned integers. Similarly , there’s no need to add unsafe
unchecked_divmethods for unsigned integers because the safeDivimplementations already achieves the same effect (those impls use theunchecked_divintrinsic internally, and callers that need to unsafely assert that the RHS is non-zero can combine it withNonZero::new_unchecked), andunchecked_divfor signed integers could also take aNonZeroRHS and only require callers to check the “no overflow” condition.For the safe version this makes sense but for
unchecked_exact_divit’s not obvious to me that UB is the right choice. Having three distinct preconditions to check (no remainder, no division by zero, no overflow) is not great because it’s easy to forget one, especially the overflow edge case.No, there is only one unsafe precondition:
a.exact_div_unchecked(b)is only allowed if there is a numbercsuch thatb * c == a(without overflow). The three cases are just a consequence of that.An "unchecked" method panicking on some inputs would be quite surprising.
This “single” precondition leaves a third of the work to the “(without overflow)” and isn’t even correct: a = b = 0 is UB but c = 0 satisfies b * c = a.
In any case: even if there is some clever way to subsume all three conditions in a single one, that’s of little use to unsafe code authors if the generality makes it easy to overlook edge cases or difficult to connect to the concrete facts available at the call site.
This “single” precondition leaves a third of the work to the “(without overflow)” and isn’t even correct: a = b = 0 is UB but c = 0 satisfies b * c = a.
You're right, it should be a unique number
c.This came up in the @rust-lang/libs-api meeting while discussing rust-lang/libs-team#570.
We think that the unchecked version is valuable because it exposes the lowest-level primitive which others can build around. Only exposing higher-level wrappers can end up being harder for users to work with.
However we did feel that there was little value to the panicking version, especially since it can be emulated by calling
.unwrap()on the result of the checked version (which additionally has the advantage of making it clear this is a potential panic point). As such we would like the panicking version removed and thechecked_prefix to be removed on the checked version.Regarding naming, in the meeting there was a preference for
exact_divandexact_div_unchecked, the reasoning being thatunchecked_exact_divcan be ambiguous as to whether "unchecked" refers just to "exact" or the entire "exact_div" operation.Reacted by Waleed DahshanI don't think I'm on board with the checked variant dropping the
checked_prefix. From my comment on the ACP:As of today, every single method on integer types (as far as I can see) that returns an
Optionstarts with achecked_prefix. I'm not one for a foolish consistency, but I think it makes sense here.We should just keep that prefix given how strong the convention already is.
The other benefit of using the
checked_prefix is that it leaves room for adding the panicking variant in the future, should that become better motivated.Could the libs-api members who want to drop the
checked_prefix say more about that here?Reacted by Clar Fon, Artyom Pavlov, kennytm, Zavier Divelbiss and Max Heller39 remaining items
- added a commit that references this issue
on Dec 21, 2025 - added a commit that references this issue
on Dec 29, 2025 - added a commit that references this issue
on Mar 27, 2026 I think it would make sense to implement these on
NonZeroas well sincex.exact_div(y)will never be zero if x is not zero.Reacted by Martin Habovštiak, sendittothenewts and Ronno DasReacted by Gabriel Bjørnager Jensen- added a commit that references this issue
on Jun 25, 2026 - added a commit that references this issue
on Aug 7, 2026
View all comments
Feature gate:
#![feature(exact_div)]This is a tracking issue for exact division methods (i.e. for division without remainder) on primitive integer types.
Public API
Steps / History
((un)checked_)exact_divmethods for integer types libs-team#337Unresolved Questions
exact_div: Add((un)checked_)exact_divmethods for integer types libs-team#337 (comment)