Feature request: `NonZeroU*` structs

[al8n]

Hi, thanks for the amazing crate. May I ask to support NonZeroU* structs?

[vortexofdoom]

Is your use case for these something that would be covered by a crate-wide niche optimization implementation? (ie. just having a NonZeroU* be the same size as a U*) A decent NonZeroU* wrapper would probably require that regardless (you wouldn't want a 2-byte NonZeroU4), and if it was there, I almost wonder whether it would even be worth including directly in the crate, since no further optimization would be needed to make a naive implementation take advantage of the niche optimization (since for all of the non-native types, there's already a niche even without excluding 0, and for native types you have std::num::NonZero to enable those optimizations.)

I'm hoping to get back to this soon, was just wondering if the niche optimization alone would be sufficient, as thus far this crate has leaned pretty heavily toward not adding a ton of stuff. It wouldn't be a terribly complex feature, though, and could reasonably be behind a cargo feature if it's decided that it merits doing.

[al8n]

Hi, in my use case, I just want NonZeroU* has the same size as U*.

[vortexofdoom]

Looking further into it, any kind of niche optimizations (including NonZero) will be kind of tricky to make work with the const generic structure of this crate. I don't exactly think it's impossible, but the long and short of it is that it will require the user facing structs to not directly contain a u32 or whatever, but instead a custom #[repr(C)] struct built from enums that enforce the compile-time limits.

You can get away with only specifying #[repr(u8)] enums for 7 bits and below (including 0), then building the rest out of those and u8, and const generics could possibly be leveraged in the building of these inner structs, but I'm not sure it could be kept as lightweight as the current implementation.

[danlehmann]

Not in principle against this, but I think this would add a ton of code and complexity. Also NonZeroU1 is somewhat funny as it can only be 1 :)

[IvarWithoutBones]

Looking further into it, any kind of niche optimizations (including NonZero) will be kind of tricky to make work with the const generic structure of this crate. I don't exactly think it's impossible, but the long and short of it is that it will require the user facing structs to not directly contain a u32 or whatever, but instead a custom #[repr(C)] struct built from enums that enforce the compile-time limits.

I'm not entirely sure why that'd be necessary for NonZero specifically? I imagine such a structure would allow for niche optimisations to use the upper unoccupied bits (which would apply to the regular uX types as well), but it seems like the standard library already takes care of the zero case here:

#[repr(transparent)] // Ensure we have the same layout as T
struct UInt<T, const BITS: usize> {
    value: T
}

type NonZeroU1 = UInt<core::num::NonZeroU8, 1>;

That'd require us to:

• Implement Integer for {Int,UInt}::<NonZeroX>. If we claim that UnderlyingType = X users could just interact with primitives, they won't need to use the standard library's NonZero types directly.
• Add NonZeroX to the list of primitives for which we generate const-friendly functions. This might be slightly annoying because we'd need to add an .get() call to self.value in a few places, but it should be fairly simple.

The trait implementations are already generic over the underlying type, so those shouldn't be any extra work.

Am I missing something?

[vortexofdoom]

That's a great point, I was so carried away with the general case for the niche optimization that I overlooked the fact that the standard NonZero could work as-is.

[danlehmann]

One issue with the Integer trait is that it has const ZERO: Self;. That would obviously not work for the NonZero variants