1/15/2025 at 7:25:16 PM
But why? It's roughly the same as JSON, but incompatible. Please, stop writing your own JSON variants.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.
by Animats
1/15/2025 at 8:28:25 PM
I know of one format that serde's system doesn't support well. D-Bus requires empty arrays to be aligned according to the type of their element, but serde's system has no way to tell the serializer any metadata about the type of an array element apart from giving it the array element to serialize. All the serializer gets to know that an array has started and then ended; it doesn't know anything about the element alignment unless it receives at least one element.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.
by Arnavion
1/15/2025 at 7:28:25 PM
> But why?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.
by airstrike
1/15/2025 at 9:29:34 PM
As a comparison, here's the "Why RON" for the native RON/Rust format: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)
by Rantenki
1/16/2025 at 8:38:45 AM
So basically JSON5, while not being a standard.by pjmlp
1/16/2025 at 5:16:56 PM
> • Allow commentsOk, 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? */by cryptonector
1/17/2025 at 1:52:29 AM
Just drop the comments. They are comments, which means they should be ignored when parsing. I just want to be able to parse files with comments instead of getting an error. Same for trailing commasby airstrike
1/17/2025 at 7:01:17 PM
Sure, no problem. But then your users will ask you to preserve comments. How do I know? Because we've seen that request in jq multiple times.by cryptonector
1/16/2025 at 5:09:33 PM
This has just enough type information in the encoded form. You can do that in JSON too, by convention, of course. There's also an aesthetics argument. Idk, I think this is fine, and probably desirable in some contexts, but yes, it's an Nth system syndrome.by cryptonector
1/15/2025 at 8:26:29 PM
Because JSON is explicitly meant for machines only?by searealist
1/16/2025 at 5:20:35 PM
Where in RFC 8259 is this stated?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.
by cryptonector
1/17/2025 at 5:47:09 AM
"data interchange format" is synonymous with what I said. Also consider there are no comments.by searealist
1/17/2025 at 7:00:33 PM
That's not how reality works.by cryptonector