`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:

• [x] #357
• [ ] #328
• [ ] #255
• [x] #217
• [ ] #189
• [ ] #140
• [ ] #122
• [x] #115
• [x] #407
• [x] #456
• [x] #445
• [x] #436
• [x] #438
• [ ] #411
• [x] https://github.com/ron-rs/ron/pull/481#issuecomment-1688676883
• [x] #488
• [x] #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?