Do not require parentheses around struct enum variant with default values

[mierak]

Currently we are required to specify at least empty set of parentheses after the enum variant name when deserializing a struct variant which has all fields marked with #[serde(default)].
I find myself converting my unit variants to struct variants and this would make it possible to extend them in a backwards compatible way instead of having to create an empty struct variant from the get go.

Example to illustrate the issue:

use serde::Deserialize;

#[derive(Deserialize)]
enum Foo {
    A,
    B {
        #[serde(default)]
        field: String,
    }
}

fn main() {
    let a: Result<Foo, _> = ron::de::from_str("A");
    let b: Result<Foo, _> = ron::de::from_str(r#"B(field: "value")"#);
    let c: Result<Foo, _> = ron::de::from_str("B()");
    let d: Result<Foo, _> = ron::de::from_str("B");

    assert!(a.is_ok()); // Ok
    assert!(b.is_ok()); // Ok
    assert!(c.is_ok()); // Ok
    assert!(d.is_ok()); // Not Ok
}

Would it be possible to make the option d deserialize with default values in the same fashion as option c does?

[juntyr]

Thank you for the question!

At the moment, it is unfortunately not possible to support this.

While we could add a special case to typed deserialisation (when calling deserialize_enum), it wouldn't work for untyped deserialisation (deserialize_any), which is invoked e.g. when inside an untagged enum variant. If/when serde allows formats like RON to supply their own custom Content type during untyped deserialisation, we might be able to support it.

However, it would also slightly go against Rust syntax, since struct variants are different from tuple variants are different from unit variants. So if we added this syntactic sugar, it would be as a feature that needs to be explicitly enabled (similar to implicit some).

[mierak]

Thank you for the reply as well!

I understand that it is not possible with the current version of serde and why you are hesitant to add this in the first place. With that said, I am also ok with this being gated behind an extension if this was to be ever implemented.