Tracking Issue for NonZero_c_* integers

[KodrAus]

Feature gate: #![feature(raw_os_nonzero)]

This is a tracking issue for non-zero variants of c_int type aliases.

Public API

pub type NonZero_c_char = NonZero?8;
pub type NonZero_c_schar = NonZeroI8;
pub type NonZero_c_uchar = NonZeroU8;
pub type NonZero_c_short = NonZeroI16;
pub type NonZero_c_ushort = NonZeroU16;
pub type NonZero_c_int = NonZeroI32;
pub type NonZero_c_uint = NonZeroU32;
#[cfg(any(target_pointer_width = "32", windows))]
pub type NonZero_c_long = NonZeroI32;
#[cfg(any(target_pointer_width = "32", windows))]
pub type NonZero_c_ulong = NonZeroU32;
#[cfg(all(target_pointer_width = "64", not(windows)))]
pub type NonZero_c_long = NonZeroI64;
#[cfg(all(target_pointer_width = "64", not(windows)))]
pub type NonZero_c_ulong = NonZeroU64;
pub type NonZero_c_longlong = NonZeroI64;
pub type NonZero_c_ulonglong = NonZeroU64;

Steps / History

• Implementation: Provide NonZero_c_* integers #82228
• Final commenting period (FCP)
• Stabilization PR

Unresolved Questions

• Naming.....

[joshtriplett]

FCP for stabilization:

@rfcbot merge

[rfcbot]

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

Concerns:

• generic NonZero (Tracking Issue for NonZero_c_* integers #82363 (comment))

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.

[dtolnay]

NonZero_c_ulonglong

I can't say that I am thrilled about Pascal_snake_concatwords-case. Can we reconsider doing a generic type alias instead?

// core::num

/// NonZero<i8> = NonZeroI8
/// NonZero<i16> = NonZeroI16
/// etc
pub type NonZero<N> = <N as private::Primitive>::NonZero;

This would automatically be usable as NonZero<c_char> = NonZeroI8/NonZeroU8 (based on platform).

Note we don't need to make any underlying trait publicly accessible. This is not for writing generic code over all different nonzero types. It is just for saner spelling of the type names.

[joshtriplett]

If that kind of generic is possible, I'm all for it. Is it?

[Amanieu]

I also think that these names are very ugly and would vastly prefer a generic NonZero type based on a sealed trait.

@rfcbot concern generic NonZero

[kennytm]

IMO introducing AtomicT/NonZeroT replacing Atomic<T>/NonZero<T> are the gravest API mistake Rust has ever made so +1 to introducing NonZero<T> again.

The 12 NonZeroT types are introduced in rust-lang/rfcs#2307 was to sidestep the question what should happen to NonZero<CustomType>, taking the precedent of AtomicT (but disregarding Wrapping<T>).

One problem of the current API is that it is unclear what happens or what should happen to NonZero<T> or Option<NonZero<T>> when T is some type other than a raw pointer or a primitive integer. In particular, crates outside of std can implement Zeroable for their arbitrary types since it is a public trait.

To avoid this question entirely, this RFC proposes replacing the generic type and trait with twelve concrete types in std::num, one for each primitive integer type. This is similar to the existing atomic integer types like std::sync::atomic::AtomicU32.

The Motivation no longer applies since, as demonstrated in in #88990, we can make the bounding trait IntegerPrimitive (previously Zeroable) a private/sealed trait. During FCP SimonSapin did mention (in rust-lang/rfcs#2307 (comment) and rust-lang/rfcs#2307 (comment)) why this route was not considered, mainly because of type checker bugs and personal taste. It was agreed in rust-lang/rfcs#2307 (comment) that the question won't block the FCP-merge. Yet the question of generics was not checkboxed in #49137 before stabilization of NonZeroT.

---

Now that this issue shows that generics is greatly favored, I think we should better do it properly by turning NonZero<T> back to a struct, and NonZeroT direct type aliases, rather than the current implementation that NonZeroT are concrete types and NonZero<T> being an alias going jumping through associated types.

// no reexport
pub trait IntegerPrimitive: Sized + Copy + Ord + Hash + Default + BitOr<Output=Self> + Debug + Display + Binary + Octal + LowerHex + UpperHex {}

#[unstable(...)] 
#[derive(Copy, Clone, Eq, PartialEq, Ord, PartialOrd, Hash)]
#[repr(transparent)]
#[rustc_layout_scalar_valid_range_start(1)]
#[rustc_nonnull_optimization_guaranteed]
pub struct NonZero<T: IntegerPrimitive>(T);

impl<T: IntegerPrimitive> NonZero<T> {
    #[stable(..)]
    pub const unsafe fn new_unchecked(n: T) -> Self { unsafe { Self(n) } }
    pub const fn new(n: T) -> Option<Self> { (n != T::default()).then(|| unsafe { Self(n) }) }
    pub const fn get(self) -> T { self.0 }
}

#[stable(..)]
impl<T: IntegerPrimitive> BitOr for NonZero<T> {}

//... etc ...

#[stable(..)]
pub type NonZeroU8 = NonZero<u8>;
pub type NonZeroU16 = NonZero<u16>;
...
pub type NonZeroI128 = NonZero<i128>;
pub type NonZeroIsize = NonZero<isize>;

the inherent functions leading_zeros, trailing_zeros, {checked,saturating,unchecked}_{add,mul,pow}, checked_next_power_of_two, abs, {checked,overflowing,saturating,wrapping,unsigned}_abs, is_power_of_two still require per-instance impl by macro.

[joshtriplett]

I'd be happy to review a pull request adding a generic NonZero based on a sealed trait.

[joshtriplett]

Cancelling in favor of generic NonZero.
@rfcbot cancel

[rfcbot]

@joshtriplett proposal cancelled.

[CAD97]

Just as a note: std is missing a reëxport of these names from core.

[reitermarkus]

I had a go at implementing a generic NonZero type here #100428.

[briansmith]

NonZero_c_size_t and NonZero_c_ptrdiff_t are missing from core::ffi.

[dtolnay]

Superseded by #120257.