Repository navigation
Tracking Issue for generic NonZero #120257
Description
Feature gate: #![feature(generic_nonzero)]
This is a tracking issue for replacing the distinct NonZero* types with a generic NonZero<T> type. This allows using NonZero with FFI type aliases instead of having weird type names like NonZero_c_ulonglong.
This replaces the following tracking issues:
Public API
use core::num::{NonZero, NonZeroU8};
assert_eq!(NonZero::new(33u8), NonZeroU8::new(33));Steps / History
- Initial implementation attempt: Add generic
NonZerotype. #100428 - Consolidate all associated items on the NonZero integer types into a single impl block per type #118665
- Add private
NonZero<T>type alias. #119990 - Manually implement derived
NonZerotraits. #120160 - Switch
NonZeroalias direction. #120165 - Use
SelfinNonZero*implementations. #120244 - Make
NonZeroconstructors generic. #120521 - Use
transmute_uncheckedinNonZero::new. #120809 - Make
NonZero::getgeneric. #120563 - Use generic
NonZerointernally. #120486 - Make other methods generic. (optional, can happen after stabilization)
- Refactor trait implementations in
core::convert::num. #121277 - Use generic
NonZeroeverywhere inlibrary. #121454 - Use generic
NonZeroin tests. #121461 - Make
ZeroablePrimitivetrait unsafe. #121850 - Final comment period (FCP)1
- Stabilization
- Generic
NonZeropost-stabilization changes. #124587
Unresolved Questions
- None yet.
Activity
Rollup merge of rust-lang#120295 - reitermarkus:remove-ffi-nonzero, r…
Unrolled build for rust-lang#120295
reitermarkus commentedon Jan 31, 2024
@dtolnay, given the documentation issue, making
NonZero::newand other constructors generic can really only be done during/after stabilization, so the only blocker I can see right now is stabilization itself. Can this enter FCP, or do we want to wait for #120486?Rollup merge of rust-lang#120521 - reitermarkus:generic-nonzero-const…
Rollup merge of rust-lang#120521 - reitermarkus:generic-nonzero-const…
Rollup merge of rust-lang#120521 - reitermarkus:generic-nonzero-const…
Rollup merge of rust-lang#120521 - reitermarkus:generic-nonzero-const…
Rollup merge of rust-lang#120521 - reitermarkus:generic-nonzero-const…
Rollup merge of rust-lang#120521 - reitermarkus:generic-nonzero-const…
Rollup merge of rust-lang#120521 - reitermarkus:generic-nonzero-const…
Auto merge of rust-lang#120521 - reitermarkus:generic-nonzero-constru…
Auto merge of rust-lang#120521 - reitermarkus:generic-nonzero-constru…
93 remaining items
Auto merge of #120486 - reitermarkus:use-generic-nonzero, r=dtolnay
Auto merge of #120563 - reitermarkus:generic-nonzero-get, r=dtolnay
Auto merge of #121461 - reitermarkus:generic-nonzero-tests, r=dtolnay
Auto merge of #121885 - reitermarkus:generic-nonzero-inner, r=oli-obk…
Rollup merge of rust-lang#124587 - reitermarkus:use-generic-nonzero, …
Rollup merge of rust-lang#124587 - reitermarkus:use-generic-nonzero, …
Unrolled build for rust-lang#124587
Rollup merge of #124587 - reitermarkus:use-generic-nonzero, r=dtolnay
Rollup merge of #124587 - reitermarkus:use-generic-nonzero, r=dtolnay
Rollup merge of #124587 - reitermarkus:use-generic-nonzero, r=dtolnay
Rollup merge of rust-lang#130543 - CAD97:generic-atomic, r=Noratrieb
Auto merge of rust-lang#130543 - CAD97:generic-atomic, r=Noratrieb
dhardy commentedon Nov 19, 2025
This issue is marked as closed, yet it depends on an unstable trait:
ZeroablePrimitive. This blocks a lot of use-cases.Should there be a separate tracking issue for
ZeroablePrimitive? I do not see one.RalfJung commentedon Nov 19, 2025
ZeroablePrimitiveis currently guarded by thenonzero_internalsfeature gate. The "internal" part indicates it is not intended for stabilization and therefore has no tracking issue.I would suggest filing an ACP if you want to make that trait more than just an internal implementation detail.