-
Notifications
You must be signed in to change notification settings - Fork 70
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
More than 256 enum variants #181
Comments
So far it is quite a rare case, so I would rather not complicate the code-base. If you need it, feel free to just implement borsh traits explicitly. I will keep this issue open for several months to collect further feedback and concrete use-cases if it turns out to be popular (I must admit, I doubt it is going to be the case) |
The field allows specifying how many bytes the discriminant byte takes. This in turn allows for better support of custom encoding formats with more than 256 variants and untagged unions. Issue: near#181
The field allows specifying how many bytes the discriminant byte takes. This in turn allows for better support of custom encoding formats with more than 256 variants and untagged unions. Issue: near#181
The field allows specifying how many bytes the discriminant byte takes. This in turn allows for better support of custom encoding formats with more than 256 variants and untagged unions. Issue: near#181
The field allows specifying how many bytes the discriminant byte takes. This in turn allows for better support of custom encoding formats with more than 256 variants and untagged unions. Issue: near#181
The field allows specifying how many bytes the discriminant byte takes. This in turn allows for better support of custom encoding formats with more than 256 variants and untagged unions. Issue: near#181
The field allows specifying how many bytes the discriminant byte takes. This in turn allows for better support of custom encoding formats with more than 256 variants and untagged unions. Issue: near#181
* Add Definition::Enum::tag_width field The field allows specifying how many bytes the discriminant byte takes. This in turn allows for better support of custom encoding formats with more than 256 variants and untagged unions. Issue: #181 * build: revert externing `alloc` crate when `std` is available; fix test (i+1) * chore: add `MaxSizeError::ZSTSequenceNotArray` to make `BorshSchema` more congruent with `BorshSerialize, BorshDeserialize` --------- Co-authored-by: dj8yf0μl <[email protected]>
@dj8yfo I see several PR referring to this issue. Was it resolved afterall? |
@frol I'd be happy to open a PR adding proc macro support for this. Looks like it was just added to the schema but not the actual proc macro. I'm not sure if this would require updating the borsh spec (on the website). It looks like there's support in the recommended TS bindings for this but not in the near js bindings, so I'm a bit unsure whether or not this is actually supported? |
I have a usecase where the number of enum variants is not bounded. Is support for more than 256 enum variants going to be added to borsh?
An enum attribute such as
#[borsh(repr = u32)]
should be sufficient.The text was updated successfully, but these errors were encountered: