Tracking Issue for generic NonZero

[reitermarkus]

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:

• Tracking Issue for NonZero trait #95157
• Tracking Issue for NonZero_c_* integers #82363

Public API

use core::num::{NonZero, NonZeroU8};

assert_eq!(NonZero::new(33u8), NonZeroU8::new(33));

Steps / History

• Initial implementation attempt: Add generic NonZero type. #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 NonZero traits. #120160
• Switch NonZero alias direction. #120165
• Use Self in NonZero* implementations. #120244
• Make NonZero constructors generic. #120521
• Use transmute_unchecked in NonZero::new. #120809
• Make NonZero::get generic. #120563
• Use generic NonZero internally. #120486
• Make other methods generic. (optional, can happen after stabilization)
  • Implement NonZero traits generically. #121241
• Refactor trait implementations in core::convert::num. #121277
• Use generic NonZero everywhere in library. #121454
• Use generic NonZero in tests. #121461
• Make ZeroablePrimitive trait unsafe. #121850
• Final comment period (FCP)¹
  • Move generic NonZero rustc_layout_scalar_valid_range_start attribute to inner type. #121885
• Stabilization
  • Stabilize generic NonZero. #124230
• Generic NonZero post-stabilization changes. #124587

Unresolved Questions

• None yet.

Footnotes

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

[reitermarkus]

@dtolnay, given the documentation issue, making NonZero::new and 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?

[Alonely0]

Just a thought:

I think this could potentially be made user-extensable if there was an API that looked like:

pub trait Zeroable: Copy + StructuralPartialEq + Sized {
  const ZERO: Self;
}

pub struct NonZero<T: Zeroable>(T);

impl<T: Zeroable> NonZero<T> {
  const fn new(v: T) -> Option<Self> {
    if (v == T::ZERO) {
      None
    } else {
      Some(NonZero(v))
    }
  }
  // ...
}

Could we instead have it just be an unsafe marker auto trait (without the associated const), and later on have a WithNiche trait that'd be a generalization in which the niche may or may not be a zeroed bit pattern? Your proposal seems a bit weird to me, since the compiler should be able to create a zeroed bit pattern for any known type. Furthermore, this would allow us to move this particular issue forward while we deal with the complexity of user-defined niches in a separate RFC.

Bikeshed:

use core::mem::MaybeUninit;

unsafe auto trait InvalidZeroed: WithNiche {}
unsafe trait WithNiche {
    const NICHE: Self;
}

unsafe impl<T: InvalidZeroed> WithNiche for T {
    const NICHE: T = unsafe { MaybeUninit::zeroed().assume_init() };
}

[reitermarkus]

the compiler should be able to create a zeroed bit pattern for any known type

The problem is not creating the bit pattern, it's ensuring that pattern is used as a niche, which currently can only be done with #[rustc_layout_scalar_valid_range_{start,end}], i.e. not in user code.

Furthermore, this would allow us to move this particular issue forward

Creating a user-implementable Zeroable trait is not part of this tracking issue, so this is not a blocker in any case.

[RalfJung]

Indeed, any discussion of having user-defined NonZero types is off-topic in this tracking issue.

[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.

[tmccombs]

Indeed, any discussion of having user-defined NonZero types is off-topic in this tracking issue.

I probably should have been more clear, but the reason I brought it up is I'm not sure if it is merged as is, if it would be possible to change it to allow user-defined NonZero types in the future in a backwards compatible way.

[reitermarkus]

if it would be possible to change it to allow user-defined NonZero types in the future in a backwards compatible way.

Yes, the ZeroablePrimitive trait is perma-unstable and sealed in order to avoid any compatibility issues.