Tracking Issue for negation methods on NonZeroI*

[jmillikin]

Feature gate: #![feature(nonzero_negation_ops)]

This is a tracking issue for adding negation methods such as wrapping_neg() to the core::num::NonZeroI{8,16,32,64,128} types.

ACP: rust-lang/libs-team#105

Public API

// core::num

for $Ty in NonZeroI{8,16,32,64,128} {
	pub const fn is_positive(self) -> bool;
	pub const fn is_negative(self) -> bool;
	pub const fn checked_neg(self) -> Option<$Ty>;
	pub const fn overflowing_neg(self) -> ($Ty, bool);
	pub const fn saturating_neg(self) -> $Ty;
	pub const fn wrapping_neg(self) -> $Ty;
}

Steps / History

• Implementation: Add negation methods for signed non-zero integers. #102342
• Add is_positive method for signed non-zero integers. #111186
• Final comment period (FCP)¹
• Stabilization PR: Stabilize feature nonzero_negation_ops #111044

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[jmillikin]

(pinging someone from the libs team, per instructions at https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html)

@joshtriplett 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 impl Neg is now merged (#102341).

[jmillikin]

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 #111044 to stabilize.

[BurntSushi]

@rfcbot fcp merge

This is a small collection of negation methods on the NonZeroI{8,16,32,64,128} types. Specifically, the is_negative 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 i[8,16,32,64,128} 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.

[rfcbot]

Team member @BurntSushi 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

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.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[Robbepop]

Sorry for being a bit late to the show but I just found this via TWIR.

What is the rational for leaving out an is_positive method? I know it is trivial to emulate via !n.is_negative() where n: NonZeroIxx but ...

• Rust primitive signed integers such as i32 do have both methods.
• Using the aforementioned !n.is_negative() instead of n.is_positive() when needed can be considered bad style.

[jmillikin]

Thanks for the catch! I just didn't see that is_positive() existed. Created PR #111186 to add it.

[rfcbot]

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.