search

toml-lang / toml

Tom's Obvious, Minimal Language
https://toml.io
MIT License
19.45k stars 847 forks source link

Allow newlines and trailing comma in inline tables #904

Closed arp242 closed 2 years ago

arp242 commented 2 years ago

Fixes #516

eksortso commented 2 years ago

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 commented 2 years ago

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.

eksortso commented 2 years ago

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

eksortso commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Thanks for being understanding folks! :)

ChristianSi commented 2 years ago

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

pradyunsg commented 2 years ago

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

Fair enough. :P

pradyunsg commented 2 years ago

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

dmbaturin commented 2 years ago

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

arp242 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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