Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: NonZeroU* structs #46

Open
al8n opened this issue Aug 16, 2024 · 3 comments
Open

Feature request: NonZeroU* structs #46

al8n opened this issue Aug 16, 2024 · 3 comments

Comments

@al8n
Copy link

al8n commented Aug 16, 2024

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

@vortexofdoom
Copy link

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
Copy link
Author

al8n commented Sep 5, 2024

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

@vortexofdoom
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants