Support enum in `Config::Input`

[ThierryBerger]

I would like to use enums in Config::Input to differentiate different possible inputs.

Config::Input is requiring on Pod, which has a lot of constraints, main one is that any bit patterns should be correct, making most enum potentially unfit.

The trait Pod has been split in different traits in this PR: Lokathor/bytemuck#91 ; If I'm not mistaken, ideally CheckedBitPattern should be enough.

This should enable us to have enums within Config::Input.

Somewhat related issue: Lokathor/bytemuck#84

As noted #41 (comment), I think we're dependent on bytemuck to support more than fieldless enums.

[gschup]

Easing the trait bounds on Input is generally good, we just have to check if this remains sound. If you are willing, you could give it a try. PRs are always welcome :)

[ThierryBerger]

I would not consider this closed until we support enum with fields 😈 ; supporting « only » fieldless enum is still quite a big restriction.

It might be possible to support enum with fields currently, but it requires unsafe code which can be hard to write, so I’m advocating for considering:

• an example
• a better support in bytemuck
• some helper in ggrs

[Umatriz]

I'm not very familiar with p2p networks. But why cant we allow sending any kind of data? Why cant we just serialize it and then deserialize?

[gschup]

The constraints on the data come mostly from the compression algorithm being used. If your usecase does not fit the restrictions directly, you can always serialize your inputs outside of GGRS and create Inputs based on your serialization. One important aspect is that all inputs need to have exactly the same number of bits.

[Umatriz]

Is there an example of such serialization?

[gschup]

This input encoding example is from a much older version of GGRS, but the main idea holds:
Either use an u8/u16 where each bit represents a button being pressed or not and encode the input yourself or use a library like bincode. This example does both, which is quite unnecessary :D

Basically, if you can encode your input into a single fixed-size sequence of bits, then you are good to go. With the current GGRS you can simply define the input as a u8/u16/etc that holds these bits.