-
Notifications
You must be signed in to change notification settings - Fork 7
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
modify ArraySize to allow for arbitrary size support by third parties #81
base: master
Are you sure you want to change the base?
Conversation
The invariant checker produces errors like
Which is a bit of soup - but the text "ArraySize invariant violated" does appear pretty early, also listing |
For convenience, it might make sense to introduce |
/// [`Unsigned::USIZE`]. Breaking this requirement will cause undefined behavior. | ||
/// | ||
/// NOTE: This trait is effectively sealed and can not be implemented by third-party crates. | ||
/// It is implemented only for a number of types defined in [`typenum::consts`]. | ||
pub unsafe trait ArraySize: Unsigned { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We use Unsigned::USIZE
quite a bit, FWIW. I guess all of these usages would hypothetically have to change to ArraySize::Size::USIZE
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that goes for my follow up suggestion of adding the convenience const. Although you do run into ambiguities then
So, I think something like this is interesting and something we should probably explore, but I worry about including it in the initial I'd like to keep this PR open, but I think we should skip it for |
I had this idea on discord to allow for third party crates to provide their own sizes. It means that
ArrayN<T, N>
no longer is guaranteed to always work, but it still unblocks users with odd sized arrays such that they canunsafe impl
ArraySize themselves.This also provides a best-effort invariant check that can catch wrong impls at compile time.
I appreciate if this design is undesirable, but I feel like #66 & #79 will be a never ending issue otherwise.