Jonas PlatteFeb 17

Unfair #rustlang #serde Quiz: What's the difference between these four types' deserialization behavior (ignoring the type name)?

#[derive(Deserialize)]
struct One {
field: Option<String>,
}

#[derive(Deserialize)]
struct Two {
#[serde(default)]
field: Option<String>,
}

#[derive(Deserialize)]
struct Three {
#[serde(deserialize_with = "Option::deserialize")]
field: Option<String>,
}

#[derive(Deserialize)]
struct Four {
#[serde(default, deserialize_with = "Option::deserialize")]
field: Option<String>,
}

Show threadEric McCorkle

@jplatte

Depends heavily on the Deserializer implementation, but

1) empty string deserializes as Some("")
2) empty string deserializes as None
3) empty string deserializes as Option::deserialize("")
4) empty string deserializes as None

In a format with explicit fields, 1 and 3 will fail if the field is not present, 2 and 4 will not.

Feb 17 at 3:57pmWeb
Show threadJonas PlatteFeb 17

@emc2 No, serde(default) on an Option has nothing to do with how empty strings are handled, but good guess. If you can show me a deserializer that treats empty strings differently between any of these, I'll be very surprised.

Also if by "a format with explicit fields" you mean something like JSON, you should try the absent field with serde_json, because it does not behave like you suggested ;)