Change:
/// ``` #[must_use] #[inline] <del> #[unstable(feature = "nonzero_negation_ops", issue = "102443")] </del> <ins> #[stable(feature = "nonzero_negation_ops", since = "CURRENT_RUSTC_VERSION")] #[rustc_const_stable(feature = "nonzero_negation_ops", since = "CURRENT_RUSTC_VERSION")] </ins> pub const fn is_positive(self) -> bool { self.get().is_positive() }

Discussion:
Feature gate: This is a tracking issue for adding negation methods such as to the types. ACP: [x] Implementation: [x] [x] Final comment period (FCP)[^1] [x] Stabilization PR: <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final comment period (FCP) is always needed before stabilization. This works as follows: A library API team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final comment period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- None yet. [^1]: https://std-dev-
(pinging someone from the libs team, per instructions at https://std-dev-) I'd like to start the FCP for this feature. The new methods have been in nightly since v1.66, and the the stabilization PR for is now merged ().
Timed out waiting for someone to start the FCP -- since there's not much to discuss regarding the API (it just copies the primitive types), I sent in PR to stabilize.
fcp merge This is a small collection of negation methods on the types. Specifically, the predicate, along with checked, overflowing, saturating and wrapping versions of negation with appropriate return types. These are exact copies of the corresponding methods on the types. Since negation of a non-zero value yields a non-zero value itself, these methods are overall pretty trivial. I don't see any obvious footguns.
Team member has proposed to merge this.

The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [ ] 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 for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
Sorry for being a bit late to the show but I just found this via TWIR. What is the rational for leaving out an method? I know it is trivial to emulate via where but ... Rust primitive signed integers such as do have both methods. Using the aforementioned instead of when needed can be considered bad style.
Thanks for the catch! I just didn't see that existed. Created PR to add it.
The final comment period, with a disposition to merge, as per the , 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.