You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the derive only works for structs and internally panics on simple enums.
There's some difficulties here:
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"
What happens if the user doesn't specify a repr? Do we default to e.g. u32?
The text was updated successfully, but these errors were encountered:
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++.
It would be beneficial to be able to derive
Encode
andDecode
for primitive enums (C-like enums) with a specified repr:Currently, the derive only works for structs and internally panics on simple enums.
There's some difficulties here:
The text was updated successfully, but these errors were encountered: