Derives for enums

[Kixunil]

It'd be nice if this crate supported enums too. Suggested API:

`#[derive(DecodeME)]`
#[endian_codec(tag_repr = "u16", endian = "le")] // tag will be treated as u16 and matched against the enum variants
enum Message {
    #[endian_codec(tag = 42)]
    Foo(FooStruct),
    #[endian_codec(tag = 47)]
    Bar(BarStruct),
}

I may write the PR if I need it, but don't expect it any time soon (probably not this year).

[xoac]

What is your use-case?
Truly I don't see reason to support enums - bincode is a good way to serialize objects. But if you need specified tags with enum - I will accept this PR.

[Kixunil]

In a project I worked on some time ago and is frozen currently the messages were coming in the form message_type,payload, where payload size depended on message_type. (It's MDB protocol.) I implemented it manually at that time, but if I ever revive the project and decide to clean up the code, moving it to a derive macro would be nice. I'd definitely do it myself if it happens.

[xoac]

Look at nom - it's complicated but powerful crate.

[Kixunil]

How does it solve the enum issue?

[xoac]

It's alternative proposition for parsing your MDB protocol than resolving derive support for enums.

[Kixunil]

I didn't see any derive support there, did I miss it?

[xoac]

There is no derive support it works different. I just pointed it out as possible alternative for parsing binary protocol(s) for you and anyone that would looking for similar solution.

I didn't tested it yet but it would probably work on embedded if allocator is available.

There is a great blog post about using nom in version 5.

[Kixunil]

Ah, I see. Yeah, it could be interesting alternative. My code is already written and if it gets unfrozen at any time, I will look into improving it by using nom. But I'd still like enum derives (maybe derives that can be used with nom as well.)