Enums Size Option(Feature Request)

[Dimkar3000]

It would be really convenient if I was able to configure the size of the Enum types index. I am currently writing an application that focus maximum compression of the data. The 4 byte size of the Enum size is more than the data size itself which in return makes me unable to use them. I think even at compile time or with an annotation I should be able to set the size of the Enum.

In my project no enum ever goes beyond the 512 discrete values barrier, so this is my suggestion:

• Make the size of enums or any object that gets serialized with an variable size configurable in compile time with an optional feature
• or create an annotation that allows me to set the size of variable length structs for any sub-type of a struct like this:

    #derive(BINCODE_BYTE_SIZE)
    struct Points {
         small_vac:Vec<u8> // I only allow 100 values in here
    }

[TyOverby]

Yep, this is something that I've also wanted for a long time!

I don't think that you could add it as an annotation to the struct, but it could certainly be a compile-time parameter to the bincode

[Dimkar3000]

This could be extended to any std type that get serialized as (size,[u8]) as it is also really common for strings that contains usernames, passwords, dates, to be really short. The reason a mentioned a trait annotation is to allow certain fields to be serialized with a smaller index size and others with a greater one.

If you think it is not viable then at least it should be done for Enums, as a discrete field type.

[sirkibsirkib]

I'd like to second this. Annotating the enum would be amazing! In almost all cases, a u8 would be sufficient

[Kerollmops]

Is it possible to know the number of variant of an enum ?

If so it can be possible to choose the adapted integer type to encode the variant number. For example an Option<T> could use an u8 and an enum with more than 256 variants could use an u16 and so on.

The deserialiser knows the enum type that it is decoding therefore it knows the number of variant and so the integer type to decode.

It is a breaking change to do this but it provides a perfect fit between correctness and data compression.

[ZoeyR]

Closing in favor of #319