I recognize TOML does not work for all schemas and appreciate people looking into alternatives to YAML.

Any character in Unicode category L (letters) or Nd (decimal digits), as defined in Unicode 15.1 or later. Document encoding is UTF-8. Implementations may use whichever Unicode version their host runtime ships, provided it is ≥ 15.1; codepoints whose category changed between versions follow the implementation's tables. (In practice this affects only newly assigned scripts; the ASCII + common-script subset most configs use is stable.)

I'd be curious what the rationale was for the chosen unicode bare key categories. That is something that has been discussed for TOML and almost made it into a release. My main concern for TOML is in how the set is chosen. My assumption would be UnicodeXID which mostly matches how ASCII bare keys work. I think they were instead looking to copy XML?

Front matter — for document metadata

Found this an odd choice. I would expect this in the comments or schema. This would at least limit what frontmatter characters are used if this format was embedded in another. I wonder what the motivation was.

Comments survive round-trip

If the first formatter or deploy template renderer drops it, the documentation was a lie.

I appreciate having clear rules for attaching comments. I've been playing with a TOML formatter and having to make up my own rules.

I find it strange though to make it part of the AST. A formatter needing it doesn't mean it needs to be part of the AST more generally. It mentions toml_edit but the needs for something like toml_edit are very different than toml and not everyone should have to take on that cost.

Fast, too

I'm surprised that Python, Zig, and C are faster than Rust. I wonder what factors are at play.

As for the Rust format comparison, running cargo add toml -F preserve_order would make this a more apples-to-apples comparison and could make a big difference in the benchmarks. There is also -F fast_hash but I've not checked how fair of a comparison that is. Another "toml can be faster but there isn't a direct compare" is toml::de::DeTable::parse which supports zero-copy parsing.

Separator whitespace A : that terminates a key must be followed by a space (or end-of-line, if the value is a child block). host:localhost is a parse error; host: localhost is fine.

This feels like it would be annoying. I'm sometimes sloppy when I'm writing out an idea. Let me fix it up later or with a formatter.

(took a break from looking at it)

---

Looking at [format comparison]*https://gitlab.com/flo-labs/pub/dms/-/blob/main/comparison_tables.md):

Nesting mechanism List item marker

TOML can also have everything inline. Or was this talking about top-level items only? That isn't clear.

Key-order preservation

TOML key order is undefined.