Allow newlines and trailing comma in inline tables

[arp242]

Fixes #516

[ChristianSi]

I would not delete the existing example. Looks good otherwise!

[eksortso]

Great work, @arp242. Thanks for stepping up!

Would it be worthwhile to mention, within the context of the spec as a whole, that the inline table's purpose is to make nesting simpler when needed? We threw out a chunk of formal editorializing, but I'd think just adding this one bit keeps inline tables in their proper perspective.

[arp242]

I restored the previous example and added a new one; I spent a good few minutes staring at my screen trying to think of an example of nested data, and this was the best I could come up with right now 😅

I also added a mention of "nested" in the description.

[ChristianSi]

Looks good to me!

@pradyunsg Care to take a look and merge, if you agree?

[eksortso]

This is pretty good. Could you make one subtle change to the last line? If you remove the word "data", it would then describe the types of grouped data that inline tables can help to manage.

[arp242]

I tweaked the wording now to:

They are especially useful for grouped (deeply) nested data that can otherwise quickly
become verbose.

which I felt was a better phrasing, and should address the intent of your comment.

[ChristianSi]

I must admit that I liked @eksortso 's wording better. "grouped (deeply) nested data" just feels like too many adjectives in a row.

[arp242]

I preferred it exactly because it put all adjectives in one place, instead of "amending" it later.

I don't strongly care either way though; I'll leave it as is for now but I'll happily change it if eksortso or other people agree.

[eksortso]

Arguably, allowing newlines makes inline tables look less crowded, even if they aren't nested. So even with all the adjectives, it gets across the point that this change is about.

[eksortso]

Not to ignore the "grouped" part. That's also a feature, because the inline syntax puts subtables in the middle of a table block without breaking the block apart. Not being able to do so was an issue that visitors have expressed in the past.

[eksortso]

LGTM, you got this!

[eksortso]

@pradyunsg @mojombo Please review this. It's ready to merge if it's acceptable to you.

[eksortso]

@pradyunsg @mojombo Please respond. It's been over two months. If you would merge this PR, it would resolve issue #516, and it would address the deep-nesting issue that's been boiling for years. At the very least, please say something.

[pradyunsg]

I’ve been swamped by a few IRL things, so I’ve not been looking to closely at this repository. I’ll make some time this week and catch up. 😅

[eksortso]

Thanks, @pradyunsg. One way or another, this PR will be a big hit with us.

And speaking as a guy with IRL problems of his own, I will tell you now, I am grateful to you.

[pradyunsg]

Thanks for being understanding folks! :)

[ChristianSi]

We are very understanding ... but only as long as you don't run away again! (insert threatening face)

[pradyunsg]

LGTM, with A couple of language nit picks.

[pradyunsg]

as long as you don't run away again! (insert threatening face)

Fair enough. :P

[pradyunsg]

Thanks for the PR @arp242 and for the discussions here everyone! :)

[dmbaturin]

That's great to see! Two questions, though:

• Will there be a TOML 2.0 spec now to accomodate the change? When can we expect it?
• What do you folks think about best practices for tools that output TOML? Should they offer a version switch and default to 1.0 so that older library/tool versions can read their output?

[arp242]

Will there be a TOML 2.0 spec now to accomodate the change? When can we expect it?

One thing that we need to do is write test cases in toml-test for all the new behaviours before we tag/release a new version. Once it's decided "yup, we've done everything we want to do for a new release" someone will need to spend some time on that (if someone hasn't already). There's a -toml flag now to set the version, so we can add as many tests for new behaviour as we want without breaking the 1.0 tests.

(Also: I assume that with "TOML 2.0" you mean "a new version"; I don't there will ever be an incompatible 2.0; the next version will most likely be 1.1).

What do you folks think about best practices for tools that output TOML? Should they offer a version switch and default to 1.0 so that older library/tool versions can read their output?

That's up to you. I bet that >95% of TOML files are read by one application only.

[dmbaturin]

That's up to you. I bet that >95% of TOML files are read by one application only.

I'm talking about tools like linters and formatters. Their output is by definition meant to be read by other applications. However, the situation with newer TOML versions support in the ecosystem is dire: most libraries listed in the wiki still don't even support 1.0! I believe some written best practice advice is needed.

[marzer]

However, the situation with newer TOML versions support in the ecosystem is dire

That's not a good-faith read of the situation, methinks. Practically all of the actively-maintained implementations are v1.0.0-compliant. The implementations listed on the wiki under v0.5.0 and below are basically all dead/abandoned projects.

[arp242]

most libraries listed in the wiki still don't even support 1.0

I'm not sure how up-to-date the wiki is, plus many libraries listed there are unmaintained. For example for C♯ it lists:

v1.0.0 compliant

	7 months - 130 stars - https://github.com/dezhidki/Tommy
	6 days   -  57 stars - https://github.com/SamboyCoding/Tomlet
	1 month  - 218 stars - https://github.com/xoofx/Tomlyn 

v0.5.0 compliant

	2 years -   4 stars - https://github.com/DanielArgent/Tomen
	2 years - 222 stars - https://github.com/paiden/Nett (archived)

v0.4.0 compliant

	7 years - 7 stars - https://github.com/azyobuzin/HyperTomlProcessor 

Unknown (or pre-v0.1.0) compliance

	 6 years -  16 stars - https://github.com/LBreedlove/Toml.net
	10 years -   6 stars - https://github.com/RichardVasquez/TomlDotNet
	 9 years -  43 stars - https://github.com/rossipedia/toml-net 

So basically, all the v0.5.0-compliant ones are unmaintained.

I just listed the C♯ ones because that happened to be the top one, but I bet the situation is similar for many other languages.

Someone should probably clean up the wiki a bit.

Other than that, I would say "use your best judgement". Different projects can make different reasonable decisions here: some might want to update to TOML 1.1 as soon as possible and that's completely fine, others might want to stick with 1.0 (or even 0.5) for a long time, and that's fine too. I don't think there is "one right way" to go about this.

[eksortso]

For what it's worth, my take is that the changes don't merit a v2.0 because they don't break valid v1.0.0 configs. There are still significant open PRs like #891 that are backwards compatible, so perhaps a v1.1.0 is worth considering?

Output tools should write configs that the input tools can read. That's the be-all and end-all of it. Revisit the second question when parsers start to accept newlines in inline tables.

[pradyunsg]

This will be in a 1.1.0. I'm not gonna commit to a timeline for that tho.

What do you folks think about best practices for tools that output TOML? Should they offer a version switch and default to 1.0 so that older library/tool versions can read their output?

Well, it depends. If they're style-preserving, sure -- preserve it. If they're regular dumps, and they can preserve 1.0 compat, it's reasonable too. I think it's reasonable to trust each parser/dumper author to figure out what makes sense for their library and how many knobs they wanna give their users.

[KaKi87]

This will be in a 1.1.0. I'm not gonna commit to a timeline for that tho.

Hello, it's been more than a year since you said that, any news ? Thanks

[eksortso]

Well this PR was merged, but we're discussing TOML 1.1.0 over at #928.