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

More than 256 enum variants #181

Open
mahkoh opened this issue Jul 15, 2023 · 3 comments
Open

More than 256 enum variants #181

mahkoh opened this issue Jul 15, 2023 · 3 comments

Comments

@mahkoh
Copy link

mahkoh commented Jul 15, 2023

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.

@frol
Copy link
Collaborator

frol commented Jul 15, 2023

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)

mina86 added a commit to mina86/borsh-rs that referenced this issue Sep 8, 2023
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
mina86 added a commit to mina86/borsh-rs that referenced this issue Sep 9, 2023
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
mina86 added a commit to mina86/borsh-rs that referenced this issue Sep 9, 2023
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
mina86 added a commit to mina86/borsh-rs that referenced this issue Sep 9, 2023
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
mina86 added a commit to mina86/borsh-rs that referenced this issue Sep 9, 2023
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
mina86 added a commit to mina86/borsh-rs that referenced this issue Sep 9, 2023
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
dj8yfo pushed a commit that referenced this issue Sep 11, 2023
* 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]>
@frol
Copy link
Collaborator

frol commented Oct 3, 2023

@dj8yfo I see several PR referring to this issue. Was it resolved afterall?

@stegaBOB
Copy link

@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?

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

3 participants