Tracking Issue for `nonzero_ops`

[iago-lito]

Feature gate: #![feature(nonzero_ops)]

This is the tracking issue for #82703. The common arithmetic operators that keep the invariants of NonZero* types enforced are implemented for these types.

Public API

Example with U8/I8, but same for U16/I16 etc.

// core::num

impl NonZeroU8 {
    pub const fn checked_add(self, other: u8) -> Option<Self>;
    pub const fn saturating_add(self, other: u8) -> Self;
    pub const unsafe fn unchecked_add(self, other: u8) -> Self;
    pub const fn checked_next_power_of_two(self) -> Option<Self>;
}

impl NonZeroI8 {
    pub const fn abs(self) -> Self;
    pub const fn checked_abs(self) -> Option<Self>;
    pub const fn overflowing_abs(self) -> (Self, bool);
    pub const fn saturating_abs(self) -> Self;
    pub const fn wrapping_abs(self) -> Self;
    pub const fn unsigned_abs(self) -> NonZeroU8;
}

impl NonZeroU8 /* and NonZeroI8 */ {
    pub const fn checked_mul(self, other: Self) -> Option<Self>;
    pub const fn saturating_mul(self, other: Self) -> Self;
    pub const unsafe fn unchecked_mul(self, other: Self) -> Self;
    pub const fn checked_pow(self, other: u32) -> Option<Self>;
    pub const fn saturating_pow(self, other: u32) -> Self;
}

/* Not yet on nightly, as it is insta-stable:
impl Neg for NonZeroI8 {
    type Output = Self;
    fn neg(self) -> Self;
}
*/

Steps / History

• Implementation: Implement nonzero arithmetics for NonZero types. #82703
• Merge Mark unsafe methods NonZero*::unchecked_(add|mul) as const. #87910 marking unsafe methods as const.
• Final commenting period (FCP)
• Stabilize checked methods in Partial stabilization of "nonzero_checked_ops". #97547.
• Stabilize unchecked_ methods.
• Add impl Neg for NonZeroI*, which could not be feature-gated.

Unresolved Questions

• Should unchecked_add and unchecked_mul be marked const and how? Would it imply that their const-ness for the underlying types be upgraded in std?
  -> Leave as-is (non-const) until add const-ub RFC rfcs#3016 lands. (Implement nonzero arithmetics for NonZero types. #82703 (comment))
  -> It has landed now, mark them const in Mark unsafe methods NonZero*::unchecked_(add|mul) as const. #87910.
• Naming: how to avoid confusion regarding the term (un)checked, referring to checking for nonzeroness in std with the NonZeroInt::new_unchecked method, but here referring to checking overflow? Discussion here.
  -> check consistently means "check everything that needs be checked in the current context, and refer to the doc to verify what needs to be checked in this context". The doc has been made explicit about what needs to be checked for every method above.

[iago-lito]

-> Leave as-is (non-const) until rust-lang/rfcs#3016 lands. (#82703 (comment))

How to not forget re-checking the constness of unchecked methods when this happens? Is there a way to leave some kind of mark in the repo that'll automatically trigger this discussion again when it's time?

[programmerjake]

-> Leave as-is (non-const) until rust-lang/rfcs#3016 lands. (#82703 (comment))

How to not forget re-checking the constness of unchecked methods when this happens? Is there a way to leave some kind of mark in the repo that'll automatically trigger this discussion again when it's time?

rust-lang/rfcs#3016 has landed...hoping these can be stabilized soon!

[Noratrieb]

I just had a use for this, what's the state of this feature?

[iago-lito]

Hi @Nilstrieb @jschwe. The state is that I don't quite know what's next. IIUC someone needs to write a stabilisation report for the feature to move forward, but this requires that a few use cases be collected first, right? I don't have many on my side, since I think I've only used it once then, but I'm happy to help :)

[jschwe]

@iago-lito Is nonzero_ops not just a "library feature"? Looking at the guide for Stabilizing a library feature a stabilisation report does not seem to be necessary.

[iago-lito]

Hi @m-ou-se, is this the right time to ask for a FCP on this feature?

[m-ou-se]

I've updated the top comment with an up to date summary of this feature.

@rfcbot merge

[rfcbot]

Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

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.