`Value` meta-issue

[juntyr]

Just to start tracking all the Value related ones - I'll try to tackle them in v0.9 and v0.10:

• Round-trip failure: untagged enum containing Vec variant is improperly deserialized #357
• Add Value::Struct variant and preserve struct names and formatting #328
• add utility methods from_reader, from_slice, from_value similar to serde_json #255
• Nested untagged and externally tagged enums fail to deserialize #217
• to_string(from_str::<Value>("ron")) should be lossless #189
• Conversion between Value and any T: Serialize/Deserialize #140
• Current issues with Value #122
• Struct flattening not working #115
• Implemented ron::value::RawValue #407
• Serialize -> Deserialize of struct crate a SpannedError #456
• plus sign on unsigned integers #445
• RON incorrectly adds extra level of Base64 when roundtripping Bytes #436
• Rusty byte strings in RON, deprecate base64 (byte) strings #438
• PrettyPrint struct names #411
• Add number suffixes and allow more number underscores #481 (comment)
• Add full UTF-8 support in RON incl. unicode identifiers #488
• Deserializer doesn't support unicode identifiers #321

[juntyr]

I've been thinking about the ron Value for a few days and wanted to summarise my thoughts:

• the Value type should be extended to be more like a ron AST (extensions excluded?)
• most issues stem from ron having a type system (in the data format) that is both more and less expressive than serde's de::Visitor API. On the one hand, ron has named units, (named) tuples, (named) struct-likes, all in addition to serde's sequences and maps. On the other hand, it does not distinguish between structs and enums.
• serialising into a Value should be no problem, but it might be useful to not make Value a Serializer itself but instead reuse the existing Serializer to benefit from the extension handling (i.e. serialising into a Value should give the ron as serialising to a String)
• deserialising from an extended Value should present little problems, but would also benefit from plugging into the existing Deserializer to handle the unwrap extensions. That way, all non-self-describing methods should work flawlessly
• deserialize_any could be adapted to support serde's untagged functionality ... to some extent (the unwrap extensions will never work with it since it requires support from our Deserializer) ... perhaps this should be a separate issue
• transforming a Value into a ron string is trivial, but could perhaps be integrated with the Serializer to support the same PrettyConfig
• implementing Deserialize for Value is the difficult part, since serde just doesn't give us sufficient information for it to work losslessly. Perhaps we should, therefore, split the functionality into (1) a Value can be serialised and deserialised by any data format - but this does not mean you can deserialise a Value from a ron string, and (2) a Value can be parsed from a ron string. This change would be breaking since Value's Serialize and Deserialize impls would do something very different from before, while the functionality of going between ron and Value would be exposed in separate methods.

@torkleyy what are your thoughts on this?