You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The specific case I'm running into that fails to round trip is serializes via Serializer::serialize_newtype_variant. I believe that this is because Value doesn't store the name of the struct stored, so deserialized named things become unnamed sequences.
I'm not sure this is possible with the current serde::Serializer trait, as serialize_newtype_variant takes a &'static str as name, which we can't get when deserializing (unless we leak a String).
I also made a simple test for the same problem but with Struct instead:
use ron::Value;
#[test]
fn struct_round_trip() {
let ron_str = "GameConfig(field: 2)";
let value: Value = ron::from_str(ron_str).unwrap();
let reserialized = ron::to_string(&value).unwrap();
assert_eq!(ron_str, reserialized);
}
It fails with "GameConfig(field: 2)" != "({\"field\":2})"
It also seems to me that the deserialization step would be impossible to implement following the abstraction proposed by serde in which Value would be independent of the serializer as Visitor does not have a visit_struct method, so there's no way to communicate to the visitor that its visiting a struct, only a map (see how deserialize_struct calls visit_map here).
Maybe there could be a hack by coupling ron::Value to ron::Deserializer and ron::Serializer.
The specific case I'm running into that fails to round trip is serializes via
Serializer::serialize_newtype_variant
. I believe that this is becauseValue
doesn't store the name of the struct stored, so deserialized named things become unnamed sequences.cc #122
The text was updated successfully, but these errors were encountered: