Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Allow arbitrary enums #6

Closed
RReverser opened this issue Dec 12, 2019 · 10 comments
Closed

Allow arbitrary enums #6

RReverser opened this issue Dec 12, 2019 · 10 comments

Comments

@RReverser
Copy link

RReverser commented Dec 12, 2019

RFC 2363 allows to set custom discriminant on arbitrary enums with payloads, and not just C-like enums.

While it's currently a nightly-only feature It's a stable feature since Rust 1.56, it would be great to support arbitrary enums in serde-repr too.

@pythonesque
Copy link

If possible, what would be great is for the discriminant to actually be passed as the variant index to crates like bincode, since this is the only way to keep serialized values "backwards compatible" when variants are removed (in the sense that variants that weren't removed will still be parsed correctly). Of course, this is dependent on the particular serializer/deserializer you use.

@RReverser
Copy link
Author

this is dependent on the particular serializer/deserializer you use

Not only - another problem is that variant index in Serde API is limited to u32 which won't fit all possible enum reprs, and won't allow to disambiguate between different repr types.

@pythonesque
Copy link

That is true, but for repr(u32) or less it would surely work :)

@elpiel
Copy link

elpiel commented Sep 10, 2020

What about using custom attribute macros? I would love to work on something like this.

This is especially useful in our case since the protocol we're implementing usually uses a value for the Enum encoded in e.g. u8, u16, etc. but contain additional data that is also serialized/deserialized and we need this to work with any arbitrary Enum but also include way to specify a custom discriminant.

Examples:

  • A container attribute like serde_repr(tag_with = "u32") that will for example do: impl TryFrom<u16> & impl Into<u16>
  • A variant attribute like serde_repr(value = "127_u32") or smth similar.

@lokegustafsson
Copy link

This seems somewhat relevant to my use case: I want to deserialize json that looks like this:

{
  "type": 5,
  "data": { ... }
}

Where the value of "type" determines which enum variant "data" should be parsed as. This is essentially the serde adjacently tagged container attribute, only with an integer instead of a string. Is this currently possible using this or with just serde?

@elpiel
Copy link

elpiel commented Oct 20, 2020

@lokegustafsson this is the exact thing we are looking to solve.
I've opened a WIP PR and would love to get some help with how to implement this 😅

@ByteAlex
Copy link

ByteAlex commented Sep 5, 2021

This feature has been stabilized in rust 1.56, are there any updates on whether or when this will be supported by either serde or serde-repr?
The linked PR #11 is stale. :/

@28Smiles 28Smiles mentioned this issue Dec 24, 2022
8 tasks
@frehberg
Copy link

frehberg commented Jan 9, 2023

support for enum-variants with fields?

serde-rep is great for binary protocols, but I face a blocker dealing with an enum with fields in variants, for example serde-repr yields error: must be a unit variant for

#[derive(Serialize_repr, Deserialize_repr, PartialEq, Debug)]
#[repr(u16)]
pub enum FooBar {
    Foo { foo: String },
    Bar { bar: String },
    Blah { blah: u32 },
}

Sadly serde-derive does not support #[repr(u16)] yet, but is serializing the discriminator as u32 always.

It would be great if serde-repr would support enum-variants with fields, as in the sample code

@dtolnay
Copy link
Owner

dtolnay commented Oct 30, 2023

I would prefer if someone else would make a different crate for this use case. I am not interested in building support for this into this crate.

@dtolnay dtolnay closed this as completed Oct 30, 2023
@RReverser
Copy link
Author

That's a shame, this crate seems like the most natural fit since they're not too different from other discriminants.

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

Successfully merging a pull request may close this issue.

7 participants