commented:
Submitting because TOML 1.1.0 allows inline tables to span multiple
lines (similar to JSON) which can make deeply-nested schemas clearer
and is the most common critique I see for the format.

  commented:
Oh wow that looks great. Deeply nested data always seemed like TOML’s
weak spot.

  commented:
I still really wish TOML had null. There are so many users of TOML
that have some value that is internally nullable and the only way to
represent it is to not set the key in the file, making merges
impossible.

  commented:
How does that make merges impossible?

  commented:
If in a commit i delete the line (to set it to null), and someone else
in another branch adds the line with another value, during merge,
there will be no conflict.
If I set the key to a null value, and someone else in another branch
sets the key to another value, there will be a conflict.

  commented:
This is a terrible solution, but using commented-out lines to stand in
for "null" should work for merging purposes.
foo = "bar"
# foo = unset


  commented:
Comments should not carry meaning and the idea to parse # key = unset
as setting a key to none is weird. It also does not help that TOML
supports nesting.

  commented:
The "default" value in some TOML files can only be expressed through
absence. So if I merge some other config on top, that sets the value
it's impossible to "unset" it since setting it to none is impossible.
Since there is little appetite to add none/null I was proposing to add
a recommendation into TOML that people should not use "absence means
null" but it did not go anywhere.

  commented:
Oh. Good to know. I'd been considering TOML, but lack of null is a
deal breaker. I need round-trip equivalence for data using a json or
json-superset data model.

  commented:
I hadn’t read the TOML specification from top to bottom before, and
I’d like to complement the authors on it. I found it well organized
and pleasing to read, introducing concepts and clarifying points just
as I got curious about them. Well done.

  commented:
looking forward to seeing this update coming to cargo and all the rest
of the rust ecosystem!

  commented:
Hasn't cargo already allowel this for ages?

  commented:
The libraries Cargo uses (toml and toml_edit) support it in their
+spec-1.1.0 versions as of today, but Cargo does not support them yet.

  commented:
IIRC Cargo was allowing multiline tables since always.

  commented:
Normal tables (with the headers) span multiple lines, but inline
tables have to be on a single line
$ cargo b
error: newlines are unsupported in inline tables, expected nothing
 --> Cargo.toml:7:11
  |
7 |   anyhow = {
  |  ___________^
8 | |   version = "1.0.100",
  | |_^


  commented:
Ah, I checked now.. turns out the actual answer is "it's
inconsistent".
At least for Cargo 1.92.0, this fails with the error you mentioned:
axum-extra = {
    version = "0.12.2",
    features = ["typed-routing"]
}

But this works just fine:
axum-extra = { version = "0.12.2", features = [
    "typed-routing"
]}

(Presumably, because in the latter case the newlines are associated
with the list, not with the surrounding table.)

  commented:
It looks nice. It does also look like support is limited so far:
https://github.com/toml-lang/toml/wiki#toml-v110

  commented:

It does also look like support is limited so far:

Well yeah, the canonical implementation only released one hour ago.

  commented:
Sure. Sometimes there's some pre-release coordination for this kind of
thing... I only posted the comment because my first action upon seeing
how much nicer the multiline inline tables were, I immediately went
groping around to see if it looked like I could use those soon.

  commented:
I was procrastinating waiting for the official release but now I'll
surely update OTOML to support 1.1. I was contemplating the idea to
allow multi-line inline tables by default and add an equivalent of the
GNU's "POSIXLY_CORRECT" flag for people who wanted to reject something
that should have always been accepted in my opinion. Now I can just
remove the restriction.
I'm also happy that using OCaml's native int and float by default no
longer makes it non-compliant. I made it so that people can bring
their own bignum library via functors because I didn't want to make
any particular library a hard dependency, but now that's also not an
issue anymore.

  commented:

I'm also happy that using OCaml's native int and float by default no
longer makes it non-compliant. I made it so that people can bring
their own bignum library via functors because I didn't want to make
any particular library a hard dependency, but now that's also not an
issue anymore.

Cool!
I didn’t mean to make it sound like anyone owes a speedy update. I
absolutely don’t believe that’s the case. I was only saying my first
reaction was “Neat feature. Can I use it? Not yet.” If it doesn’t
emerge soon after new year’s in the python version, I’ll probably look
to see if I can offer a patch at least for the nested inline tables,
because that’s going to make some of my config files easier to think
about.

  commented:
The on page syntax highlighting does this example wrong:
points = [ { x = 1, y = 2, z = 3 },
           { x = 7, y = 8, z = 9 },
           { x = 2, y = 4, z = 8 } ]

Presumably they're using an old highlighter in JS.
.