An open letter for the release of v1.1.0

[uyha]

I appreciate the efforts the maintainers are putting into the spec to make it as precisely and complete as possible. However, I am puzzled by v1.1.0 delay.

TOML is so close to being a great format, but by disallowing newlines in inline tables, it basically cripples the usage of semi-complex TOML files (array of inline tables in particular). A proposal to fix this is already accepted and slated to be released in v1.1.0, but, AFAICT, v1.1.0 is being held back by #954 and #966 (according to the milestone). In my opinion, these issues are important for the completeness of the spec, but they don't help in day to day programming as much as newlines in inline tables (no hard evidence, just my personal experience). Many parsers are also waiting for v1.1.0 to be released so they can be sure that they can implement the newlines in inline tables feature and delaying its release for these less impactful clarifications seems counterproductive.

Hence, I urge the maintainers to have v1.1.0 released and push those issues back to the next release.

[marzer]

I agree that the emoji issue isn't particularly important, but #966 is IMO. But I also believe the solution is very simple, given that there's only one solution that works everywhere TOML happens to be. Maybe I should just make a PR myself.

I also agree with the general thrust of your message; things are moving pretty slowly. That's what #895 is about. Not a simple thing to resolve, though, since it'd be a pretty big (and likely permanent) paradigm shift for the TOML language. Consider contributing to that discussion :)

[wjordan]

Many parsers are also waiting for v1.1.0 to be released so they can be sure that they can implement the newlines in inline tables feature

The toml crate is one example waiting on this release, see toml-rs/toml#397 (comment):

At this time, I'd rather not be supporting unreleased TOML specs.

At least one parser has already implemented the new changes however- the BurntSushi/toml module currently supports the current draft TOML 1.1.0 spec behind an env flag (BURNTSUSHI_TOML_110) since v1.3.0.

[arp242]

BurntSushi/toml is a bit of a special case because it's used for https://github.com/toml-lang/toml-test, and ideally I'd always like to have tests at the ready before a new TOML version. This means it will always implement things before most other implementations (or at least, for as long as I'll keep maintaining both). That's really the main reason; I added that environment variable because I figured "why not?"

If TOML 1.1 would be released today, and tomorrow a new TOML 1.2 feature would get merged, then BurntSushi/toml might very well implement support the day after, just for the tests. But that's not really a significant indicator of anything really.

That said, especially the "you can't add newlines in inline tables" does keep coming up on e.g. HN, just last week, and a few months ago, which was my main motivation for #979. I disagree with marzer that #966 isn't a big issue, and IMHO it's more than just emojis: that was just the first case I encountered; the current behaviour is basically impossible to explain to any normal non-tech person.

I don't really know what else to say about this issue to be honest. What is an "open letter" even and how is it different from "a comment"?

[uyha]

I am in no way saying that #966 is not important (I am not in the position to say what is important or not). I am trying to say that v1.1.0 should be published with the acknowledgment that there is a defect about Unicode and it has not been resolved yet. This is pragmatically useful since it lets people who encounter the Unicode problem know that it is known and being thought about, and at the same time it lets people who are not affected by this issue to start having newlines in their inline tables.

Regarding @arp242’s comment about what this issue is about. Well, I just want to have place to discuss about this, that’s all.

[arp242]

Releasing means committing to compatibility; you can't just "release it and maybe fix later" because it will narrow your options.

[uyha]

it seems like I missed the big picture. TOML v1.0.0 didn't allow non-english key and #891 introduces that capability, and it has defects that are listed out in #954 and #966. Since #891 is already accepted, release TOML v1.1.0 as is would mean that all its defects would get into the parsers, hence it's either #954 and #966 get resolved, or #891 is pulled, so that TOML v1.1.0 can be released. @arp242 is this an accurate summary?

[ChristianSi]

@uyha #954 is not a "defect" in any meaningful sense of the word, since "all emojis work as bare keys" was never a requirement. #966 is something that should be resolved before 1.1 is released (IMHO), but it concerns both bare and quoted keys and is therefore technically independent of #891 (non-ASCII in quoted keys has been allowed since ancient times).

[uyha]

I read through the issues more closely and why v1.1.0 is being blocked by them, thanks for the clarifications.

[marzer]

@arp242

I disagree with marzer that #966 isn't a big issue

Think you might have issue numbers mixed up? I said that I don't believe #954 is a big issue, but I certainly agree with you that #966 very much is. I just think that it also has a very simple and obvious solution.

[ChristianSi]

@marzer:

I just think that it also has a very simple and obvious solution.

Plus, it seems, one that everyone is now more or less in agreement on. So it really shouldn't be all that hard to get it finished...

[eksortso]

I agree that the emoji issue isn't particularly important, but #966 is IMO. But I also believe the solution is very simple, given that there's only one solution that works everywhere TOML happens to be. Maybe I should just make a PR myself.

@marzer Feel free to make the PR for #966. I've been busy and life's making me busier, which is why I've been so quiet despite recent discussion. So take the lead, use your best informed judgment, and make the PR we need to push this forward.

[marzer]

@eksortso Sure fam, think I might do it over the weekend :)