Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

derive Support for primitive enums #3

Open
ryan-summers opened this issue Nov 22, 2022 · 1 comment
Open

derive Support for primitive enums #3

ryan-summers opened this issue Nov 22, 2022 · 1 comment

Comments

@ryan-summers
Copy link
Contributor

ryan-summers commented Nov 22, 2022

It would be beneficial to be able to derive Encode and Decode for primitive enums (C-like enums) with a specified repr:

#[derive(Encode, Decode)]
#[repr(u8)]
enum States {
    Starting = 0,
    Idle = 1,
    Active = 2,
}

Currently, the derive only works for structs and internally panics on simple enums.

There's some difficulties here:

  1. Complex enums could theoretically be supported by treating internal enum data as a struct, but this starts getting into the land of "how do we specify exactly how data should be laid out"
  2. What happens if the user doesn't specify a repr? Do we default to e.g. u32?
@ryankurte
Copy link
Owner

hmm, that does seem like it'd be useful, i guess with similar consideration as to how one would support bitflags or modular-bitfield. i wonder if there's a way to blanket impl for these, but i -think- anything over TryFrom<T> + Into<T> primitives would end up conflicting with the existing impls...

Complex enums could theoretically be supported by treating internal enum data as a struct, but this starts getting into the land of "how do we specify exactly how data should be laid out"

i think if you need to specify weird enum struct storage advice would be to manually implement Encode and Decode?

What happens if the user doesn't specify a repr? Do we default to e.g. u32?

the macro is going to need to pick up the repr tag to implement the correct Encode/Decode, so, how about just failing out if it's not set? i'd rather not compile an ambiguous case than replicate the nightmare of compiler / architecture / optimisation specific enum widths in C/C++.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants