- Visualizer:
- Code:
- TOML spec:
TOML and YAML both have the problem that if you receive an incomplete document, there’s a decent chance you can’t tell. JSON doesn’t have that because of the closing curly.
That’s not a problem of a format and should be handled by transport or storage.
It very much is an aspect of the format. You may deem it unimportant, but it’s a feature that is missing from toml and yaml.
It’s not a responsibly of the format, so, at most, it’s a mere side effect. In any practical process which could result with truncated data, even if it handles data with such property, it should be wrapped in a container which includes length. At the very least, it would allow to trace the source of truncation, e.g. was the data originally truncated, or was it truncated in the process, and change the format without shooting in oneselves foot. And the generating side should always provide success flag which should be properly handled, since it may produce syntactically correct, but semantically invalid data. Such as checking exit code of process which generates json/yaml in question
What about processes that terminate before writing the whole thing? You can’t protect against everything. Blame other processes all you want but the language spec allows for confusion.
You just check the exit code, no? The other process may fail while generating syntactically correct data too, regardless of format.
I really don’t understand why people still insist on prohibiting trailing commas anywhere. The syntax is interesting but it looks like defining an array of objects would be needlessly difficult. I think the double square bracket syntax is far too easy to confuse.
Every time I have reached for TOML I have ended up using JSON. The first reason is that Python standard library can read but not write TOML, which is generally useless for me. The second reason is TOML does not add any benefit over JSON. It’s not that much easier to read and IMO JSON is easier to write by hand because the syntax rules are completely obvious.
TOML is mainly for humans to write, certainly not a good choice if you’re programmatically writing files - comments and formatting would be lost.
It all depends on the library you use. Rust has you covered with toml_edit. It is what is used for all the cargo commands editing the Cargo.toml file.
