TOML 1.1.0 released
78 points by jamesw
78 points by jamesw
Specification: https://toml.io/en/v1.1.0
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.
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.
How does that make merges impossible?
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.
This is a terrible solution, but using commented-out lines to stand in for "null" should work for merging purposes.
foo = "bar"
# foo = unset
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.
IMHO tombstones to compensate for line-oriented merges by ones VCS of choice is also a pain.
I note that mergiraf appears to do the right thing here and report a conflict.
❯ mergiraf merge base.toml left.toml right.toml
[config]
a = 1
<<<<<<< left.toml
||||||| base.toml
b = "value"
=======
b = "new value"
>>>>>>> right.toml
c = {}
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.
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.
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.
looking forward to seeing this update coming to cargo and all the rest of the rust ecosystem!
Hasn't cargo already allowel this for ages?
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.
IIRC Cargo was allowing multiline tables since always.
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",
| |_^
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.)
It looks nice. It does also look like support is limited so far:
It does also look like support is limited so far:
Well yeah, the canonical implementation only released one hour ago.
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.
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.
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.
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.