Deserializing struct inside untagged enum variant behaves inconsistently

[mierak]

Hi! Sorry for the issue name, I cannot find a better description. Anyway, there is some weirdness with untagged enum variants. Probably the best description is the contrived example below.

The deserialization works if there is a space(or any other character that does not break it in other ways really, like comments, non default fields etc). The fact that Second( ) deserializes correctly but Second() does not seems extremely weird to me. This fails with Err(SpannedError { code: Message("data did not match any variant of untagged enum Foo"), position: Position { line: 1, col: 9 } })

this is on version 0.10.1

#![allow(dead_code)]
use serde::Deserialize;

#[derive(Deserialize, Eq, PartialEq, Debug)]
#[serde(untagged)]
enum Foo {
    A(String),
    B(Bar),
}

#[derive(Deserialize, Eq, PartialEq, Debug)]
enum Bar {
    First,
    Second(Baz),
}

#[derive(Deserialize, Eq, PartialEq, Debug)]
struct Baz {
    #[serde(default)]
    first: String,
    #[serde(default)]
    second: String,
}

fn main() {
    let a: Result<Foo, _> = ron::de::from_str("\"test\"");
    let b: Result<Foo, _> = ron::de::from_str("Second(first: \"value\")");
    let c: Result<Foo, _> = ron::de::from_str("Second( )");
    let d: Result<Foo, _> = ron::de::from_str("Second()");

    assert_eq!(a, Ok(Foo::A("test".to_owned()))); // Ok
    assert_eq!(b, Ok(Foo::B(Bar::Second(Baz { first: "value".to_owned(), second: "".to_owned() })))); // Ok
    assert_eq!(c, Ok(Foo::B(Bar::Second(Baz { first: "".to_owned(), second: "".to_owned() })))); // Ok
    assert_eq!(d, Ok(Foo::B(Bar::Second(Baz { first: "".to_owned(), second: "".to_owned() })))); // This errors
}

[juntyr]

That's a fun one, thanks for the report @mierak!

So this issue goes again back to serde not allowing ron to use its own content type when deserializing without type information, which is what happens inside untagged enums. So we have to play a guessing game that plays by serde's JSON-enforced rules.

Second() currently is identified as a named struct Second which contains a unit (). Second( ) is is identified as a named struct Second, which contains an empty tuple. This is because, after parsing Second, we see (), which is always parsed as unit, but ( ) is not.

Unfortunately, then we come back to serde, which refuses to deserialize an empty tuple from unit, or unit from an empty tuple. Since ron has to guess inside deserialize_any, we have to always guess unit for ().

The ron grammar currently says that only () is unit and the parsing works this way. This could perhaps be relaxed in the future, but would again only make sense once serde allows ron to have its own content type such that it can delay the decision on what () and ( ) mean for as long as possible, until we have typed information again and know if we're supposed to deserialize a unit or a tuple.

So, unfortunately, I don't think we can fix this issue at this time. Let's hope serde-rs/serde#2912 (or a similar feature) will be merged at some point :)

[mierak]

Thank you for your response! Its unfortunate that its blocked by serde itself as well, I see you have notified the maintainer in there as too, I will keep an eye on the issue. Thanks again!