Revisit of the representation of adjacently tagged enums tag

[Baptistemontan]

This PR is a follow on #2496.

This is a proof of concept to evaluate if such feature would be interesting.

I've run some tests with serde_json and the output is the same, but still allow some format to take advantage of variant_index during serialization.

If it looks promising I can continue to work on it

[dtolnay]

I can confirm this looks promising. Thanks!

[dtolnay]

I would expect this whole type to go in serde::__private::de instead of emitting a whole new type and set of trait impls into every single use of adjacently tagged enums.

pub struct AdjacentlyTaggedEnumVariant<F> {
    tag: &'static str,
    variants: &'static [&'static str],
    fields_enum: PhantomData<F>,
}

impl<'de, F> DeserializeSeed<'de> for AdjacentlyTaggedEnumVariant<F>
where
    F: Deserialize<'de>,
{
    type Value = F;
    ...
}

[Baptistemontan]

that's what I wanted to do in the first place, but I just looked at Deserialize and because it don't take self I just moved on and did not thought of DeserializeSeed, I did something like this for serialization

[Baptistemontan]

I did not realised that DeserializeSeed was imported only with feature = "std" so I had some trouble fixing the import.

Does something like this seams more appropriate ?

[Baptistemontan]

Is there a crate implementing a binary format that use variant_index to serialize enums and support adjacently tagged enums deserialization ?

I've looked into postcard but it does'nt support deserialize_identifier and deserialize_any so adjacently tagged enums are not supported (maybe #2475 broke it?).
And I looked at ciborium but it serialize enums with the variant name.

[dtolnay]

Is there a crate implementing a binary format that use variant_index to serialize enums and support adjacently tagged enums deserialization ?

I don't know of any. But if there is, then yes, we would have heard about it breaking from #2475.

[dtolnay]

This PR is still marked as draft. Are there concrete changes planned (what are they?), or was this supposed to be ready for review?

[Baptistemontan]

@dtolnay I just forgot to open it for review, there is no changes planned

[Baptistemontan]

There is conflicts needed to be resolved, I'm gonna need some time to understand why thoses changes has been made and what can I do to not break anything.

[Baptistemontan]

All conflicts were related to the removal of try! in #2539

[dtolnay]

Thank you!

[Mingun]

This PR has some breaking changes that results in failing tests in quick-xml (tafia/quick-xml#630)

[jost-s]

Since this is a breaking change, why was it released as a patch instead of a minor version?

v1.0.180

In my case, an enum

#[derive(Serialize, Deserialize, Debug)]
#serde(tag = "type", content = "data")]
enum Message {
  A(i32),
}

let m = Message::A(100);

was rmp_serded to

[130, 164, 116, 121, 112, 101, 161, 65, 164, 100, 97, 116, 97, 100]

which the JS msgpack package converts to JSON as

{
  "type": "A",
  "data": 100
}

with serde v1.0.180.

v1.0.181

Same enum and attributes, rmp_serde spits out

[130, 164, 116, 121, 112, 101, 129, 161, 65, 192, 164, 100, 97, 116, 97, 100]

and JS msgpack converts to

{
  "type": {
    "A": null
  },
  "data": 100
}

serde_json

What is further confusing this is that converting this to JSON with serde_json results in

{\"type\":\"A\",\"data\":100}

regardless of the serde version.

rmp_serde

With serde v1.0.180 the result of rmp_serde::to_vec_named(&m) is

[130, 164, 116, 121, 112, 101, 129, 0, 192, 164, 100, 97, 116, 97, 129, 165, 112, 97, 114, 97, 109, 100]

JS msgpack decodes that to JSON like so

{
  "type": "request",
  "data": {
    "param": 100
  }
}

And with serde v1.0.181 the msgpack encoded byte array is

[130, 164, 116, 121, 112, 101, 129, 0, 192, 164, 100, 97, 116, 97, 129, 165, 112, 97, 114, 97, 109, 100]

which JS msgpack decodes to

{
  "type": {
    "0": null
  },
  "data": {
    "param": 100
  }
}

Can you please shed light on this? @dtolnay @Baptistemontan