Rust's serialization macro system allows you to write back ends for any format. I've written back ends for all three serialization formats used by Second Life.[1] (There's a binary form, an XML form, and something called "notation".) But other than for compatibility with existing code, there's no reason to use them.
There is a sort of workaround - preload into the serializer what it is expected to serialize, eg by passing in the D-Bus signature string in the serializer ctor. But a) this is a somewhat unclean solution because everything other than arrays is redundant information that the serializer already gets from the serde::Serialize impl, and b) it's manual work for the user to have to specify this and easy to make a mistake and have the two get out of sync.
In my D-Bus library I decided to have my own Serializer setup as a workaround. serde's Deserializer setup still works though so that's not a problem.
It's literally in the README...
• Less syntactic noise, more intuitive look.
• Allow comments and trailing commas.
• Write KEON almost like you write Rust:
- Humanized optional type annotation.
- Distinguishable between tuples and lists (seqs).
- Arbitrary type as dictionary (map) keys.
...
• Shorthand for newtypes.
• Support use Base64, Base32 and Base16 to represent bytes.
• Provide paragraphs may be helpful when writing something by hand.
Note the following advantages of RON over JSON:
* trailing commas allowed
* single- and multi-line comments
* field names aren't quoted, so it's less verbose
* optional struct names improve readability
* enums are supported (and less verbose than their JSON representation)
Ok, but whence the comments when serializing, and what does the codec do with comments when deserializing?
Adding comments to JSON wouldn't be hard syntactically speaking, but semantically it's a real problem not just for JSON but for every encoding where the encoded data isn't the source of truth.
Put another way, if I maintain XML, JSON, etc. by hand with $EDITOR, then embedded comments are sensible, but if XML, JSON, etc. are generated from an internal representation then now we have to wonder "what elements of the internal representation are the comments associated with, how do we ensure we represent that association when encoding, and how do we ensure that on decode we get the comments associated with the same elements.
/* Is this comment associated
with the following value?
Surely not with the preceding
one since there isn't one! */
{ "foo" /* what about this one? */:
/* or this one? */ "bar" /* or... */
}
/* And what about this one? */Any encoding meant to be decoded by machines needs to also be encoded by machines because humans are bad at hand coding. This would be true for KEON as much as for JSON.