Stabilize trait `ZeroablePrimitive`

[dhardy]

Proposal

Stabilize core::num::ZeroablePrimitive, keeping it sealed (and unsafe).

Problem statement

Since Rust 1.79, core::num::NonZero<T> is stable for T: ZeroablePrimitive. Yet, since ZeroablePrimitive is unstable, it is impossible to write generic code over NonZero.

Motivating examples or use cases

easy_cast::Cast supports numeric type conversions, a little like Into and TryInto but with different semantics. It has been requested that this support NonZero types.

The implementation of this should be fairly simple: kas-gui/easy-cast#36

Alternatives

Every "generic impl" over NonZero must instead be non-generic, likely repeated for a number of types or combinations of types using macro_rules!. The implementation of easy_cast::Conv over primitive integer types uses 29 invocations of macros, many of them recursive (covering 12 × 11 = 132 combinations IIRC).

Links and related work

Tracking issue for NonZero: rust-lang/rust#120257

[scottmcm]

The motivating example seems weak to me, since you'd still need the macros for all the primitive integer types anyway, no? At that point the extra complication from having the non-zero versions doesn't seem that bad. Especially since you'd still have all the u32: Conv<NonZero<u64>> and such that need the macro-generated per-type things anyway.

It sounds to me like what this wants is more rust-lang/rfcs#3686 (comment) so that you can just have implementations for NonZero<u<N>> and NonZero<i<N>>, rather than a blanket over ZeroablePrimitive.

Notably, it's not obvious to me that stabilizing the trait bound would even be what we want to offer, since it might close off certain things. Like we've talked about how allocators might want to only take non-ZST layouts, and if we wanted to support NonZero<Layout> to do that, then that's something pretty different from the primitives, and might end up changing how the trait works.

We already have NonZero<char>, which is pretty different from the others, so blanket impls would be a bit odd already.

[Apersoma]

Another motivating case is something like this:

trait GCD: ZeroablePrimative {
    fn(self, mut x) -> NonZero<Self>;
}

GCD as well as many other math functions return a nonzero value but take a zeroable input and either you have to add a type in GCD that specifies the return result which makes docs less clear and makes you have to do something like I: GCD<OUT=NonZero<I>> when implementating over GCD implementations or you have to have to manually implement a trait for the primatives like

Zeroable {
    type NonZero: TryFrom<Self> + Into<Self>,
}

and instead have

trait GCD: ZeroablePrimative {
    fn(self, mut x) -> <Self as Zeroable>::NonZero;
}

but that doesn't cover everything you would want from something like that because there are obviously functions implemented by NonZero that aren't in traits that you can add to the restrictions.

[programmerjake]

GCD can return a zero result, commonly gcd(0, 0) is defined to be 0.

[Apersoma]

GCD can return a zero result, commonly gcd(0, 0) is defined to be 0.

Is also often defined as undefined as there is no greatest divisor of 0

[dhardy]

Thanks for the analysis @scottmcm. I concur that this would provide only a minor benefit to easy-cast. There seems to be some unfinished business with std::num::NonZero; I guess generic integers will touch on that.

The motivation raised by @Apersoma is something usually left to Formal Methods / Verification. It would also be limited to std integers if, as in my proposal above, ZeroablePrimitive remains sealed.