Repository navigation
Support for Enums with more than 256 variants #45
Description
Are there any plans on supporting enums larger than u8? I'm currently developing a language identifier that has 238 variants for the language codes and will probably surpass that amount in the future when more languages are added.
Also, I found the error a bit confusing
error: enums with more than 256 variants are not supported
--> src/main.rs:10:10
|
10 | pub enum Lang {
| ^^^^because it does not say anything about what is causing the error. So I did not know if it was a limitation from the language, the strum derives or the bitcode derives.
Thank you very much for your library. It was one of the main optimizations I did for my tool and was able to cut down the model loading time more than a half.
Activity
caibear commentedon Sep 23, 2024
The main reason I limited enums to a 256 variants is because bitcode 0.6 requires calculating a histogram of all the variants of each enum while deserializing. With 256 variants a
[usize; 256]can be used to calculate the histogram which is quite fast. For an arbitrary number of variants aHashMap<u32, usize>is required which isn't fast.finnbear commentedon Sep 23, 2024
Perhaps an exception can be made for C-style enums, i.e. those that lack fields in their variants, which don't need a histogram.
ZJaume commentedon Sep 24, 2024
Is a
[usize; 65536]too much for that histogram?caibear commentedon Sep 24, 2024
Yes, because that would require iterating all 65536 elements to see which ones are non zero which is significant overhead.
This would only be faster than a
HashMap<u32, usize>for calculating a histogram of a very large message where the 1 time cost of iteration does not dominate the runtime.@finnbear does bring up a good point that histograms are only required non C-style enums so we could support
u16C-style enums easier.ZJaume commentedon Feb 10, 2025
Has been any progress on supporting u16 C-style enums? I'm not familiar with the bitcode source code, but could try to implement it if it's easy and you point me in the right direction.
Edit: without serde
finnbear commentedon Feb 10, 2025
No, we're not currently working on it.
caibear commentedon Feb 10, 2025
The next feature we plan to add is the ability to use serde to encode a field within the Encode macro. This provides a solution to many edge cases at once. After that we can revisit this issue and see if it's still necessary.
jstrong-lhava commentedon Aug 23, 2025
hello,
I just came across this when trying to add bitcode to give it a spin, but it would not work for an enum with more than 256 variants, which in this case, stopped me in my tracks. The enum in my case is
#[repr(u16)]and a C-style enum, so I was hoping to find some kind of escape hatch that would let me specify to just treat it as au16integer forEncode/Decode.Thanks for your work on this library! The benchmark results are impressive, eager to try it out soon.
finnbear commentedon Aug 23, 2025
Hi @jstrong-lhava; thanks for your comment! This provides motivation for supporting C-style enums with more than 256 variants. Unfortunately, there is no escape hatch other than
#[bitcode(skip)]on any un-encodable fields that you don't need to encode.448-OG commentedon Mar 22, 2026
Hi! I came across this problem too. Any progress on getting it #84 merged?