Release 1.0 final

[ChristianSi]

Since the last and final RC (rc.3) was released more than six ago and nothing important has come up since then, I'd say it's time to release TOML 1.0 final. There was only a clarification (regarding indentation) and an aesthetic fix (#784) needs to be merged before the next release.

So I'd say we don't need another RC in view of these minor changes, but can (after the merge) publish 1.0 final without further ado. Let's finish this this year!

[ChristianSi]

#769 is also still open, but as it wasn't addressed for RC.3 it doesn't look like it needs to be addressed for Final.

[eksortso]

I'm all for releasing v1.0.0 by the end of this year.

That said, I did want to include a note about the unnamed root table. It's come up a lot in discourse here, and I think it's important enough to allow for a clarification. Mind if I make a small PR?

[eksortso]

#769 fell off my radar. It ought to be addressed. The whole distinction between creating / defining / declaring tables is important enough to be included.

[eksortso]

PR #789 clarifies the status of the unnamed root table. Let me know what you think. I'll address #769 later today.

[genericptr]

Sorry if this is off-topic but I wanted to ask you guys. So, I've been using TOML for a month now and my only complaint is the restriction of new lines in inline tables. Arrays of tables are more cumbersome and have duplicate names (like target.bundle.resourcePaths_2 in this example) so tend to not use them. It's not a problem with these 2 keys but if the table gets longer then you really want some new lines to help format it.

Just curious why was this restriction imposed? Inline tables seem like a clearly better example of the new lines is kind of deal breaker unfortunately.

  target.bundle.resourcePaths_1 = [
    { source = "./Resources", destination = "${BUNDLE}/Contents/Resources" },
    { source = "./Resources", destination = "${BUNDLE}/Contents/Resources" }
  ]

[[target.bundle.resourcePaths_2]]

    source = "./Resources"
    destination = "${BUNDLE}/Contents/Resources"

[[target.bundle.resourcePaths_2]]

    source = "./Resources"
    destination = "${BUNDLE}/Contents/Resources"

[eksortso]

@genericptr TOML table sections came first, and were made to be similar to various INI formats. The array-of-tables notation was somewhat novel, but intuitively, it matched the single-bracket [table] notation well, and each instance of an [[array]]'s name indicated a new table in the array. Not too bad, but you do have to learn the double-bracket notation. It's not too cumbersome once you know where to use it.

Inline tables were introduced a few years later. They were never meant to replace the traditional tables. The intent was to offer an easy way to inject small, self-contained tables into a configuration. Making them single-line only was a deliberate design choice. We didn't want to make a JSON-like format. I initially railed against such an approach, but suggested a multi-line variant of the inline table when I realized that some tables do work better inside others. We found a better way of doing this, and I later withdrew my proposal. Probably for the best.

Since the elements of your table array are sufficiently big, I'll recommend that you stick with the table-array syntax. The duplication of names is a minor inconvenience, but you never lose your context. There is a proposal, #744, to shorten the length of those table names which has gotten some traction, but it's labeled for post-v1.0.0.

You can simplify what you've got by dropping the extra lines and indentation. Consider this variant of your second example. Is it more convenient?

[[target.bundle.resourcePaths_2]]
source = "./Resources"
destination = "${BUNDLE}/Contents/Resources"

[[target.bundle.resourcePaths_2]]
source = "./Resources"
destination = "${BUNDLE}/Contents/Resources"

[[target.bundle.resourcePaths_2]]
source = "./Resources"
destination = "${BUNDLE}/Contents/Resources"

[genericptr]

I see, thanks for your explanation. #744 is on the right track. There seems to be a need for "nesting" or inheritance in the table structure. That would make the array of tables much more appealing to me.

[eksortso]

@genericptr Well, tables are nested logically; you can set up subtables easily with headers. They're just not nested by the standard table syntax.

That design was a choice made to keep config tables as flat as possible, without preventing them from being nested when the need arises. Whether deeper nesting ought to be made easier is an open question, and there is an active issue related to that.

[eksortso]

Another historical fact about TOML was that its inception was partly a reaction to YAML. The first few versions read like a manifesto, all taking YAML to task for not being obvious or minimal.

@genericptr TOML, unlike YAML, has no concept of "inheritance." The data types typically used to interpret TOML are simple data types (maps, lists, etc.), similar to the types used by JSON decoders. They're not built up by the configuration. That's the app's job.

Reiterating: Tools written to use TOML need to take configuration logic into account. Much of the crazy logic stuffed into YAML is instead handled as needed by the TOML-consuming application.

[brunoborges]

I believe that we have stressed out as much as what could be discussed around #744.

I wonder if we could vote about adding it to 1.0.

[eksortso]

We really can't. We'd already put out rc1 before #744 was opened. @pradyunsg likes the idea but probably would not consent to adding a new feature so late in development.

[ChristianSi]

Just a quick reminder that it would be good to finish this this month. @pradyunsg What's your status?

[pradyunsg]

I'm all for releasing v1.0.0 by the end of this year.

Ditto.

@pradyunsg likes the idea but probably would not consent to adding a new feature so late in development.

Indeed.

@pradyunsg What's your status?

Added "TOML catchup" as a TODO for the weekend.

Between relocation, new job, pip's new dependency resolver and (vague gestures at the state of the world), I've not really had much free time over the past (checks notes) 5 months. :)

FWIW, the only bit I had on my personal "nice to have" list was wrapping up toml-compliance. FWIW, it takes a lot more mental work that I'd anticipated, so it's been sitting idle for quite a while now. :)

[pradyunsg]

Weekend is over!

I don't think there's anything outstanding for 1.0 and it seems very unlikely that I'll be able to get to toml-compliance this year (which SUCKS). At this point, I don't think there's anything else left to do.

I'll do one more pass of the spec, and then sometime after Christmas, tag+release 1.0.0 in 2020. ^>^

[eksortso]

Oh I've got to pick up the ball I dropped, regarding #769. I'd started work on the notions of declaring, creating, and defining tables as separate concepts, in order to add some clarity to how and why tables are made with TOML's syntax.

I won't have much time for it this week, but I could use a PR I'm already working on as a starting point at least. Anyone mind if I open a new issue to dole out some related talking points?

[eksortso]

Alright, I found the time to compile the guiding principles around how tables and table arrays are produced. Have a look at #795. What I have there isn't the PR in progress, but an effective collection of the expected behaviors that have been discussed in issues past and present. It's what we've generally agreed upon in our collective interpretations, and it will inform the changes made in the PR, which I'll have out in public within the next 72 hours.

[eksortso]

We're so close to release. @pradyunsg you've been way busy, based on what you've said, so I wouldn't push this too hard. So let me ask: Anything we can do to expedite the release of TOML v1.0.0 to this hungry world?

[pradyunsg]

Anything we can do to expedite the release of TOML v1.0.0 to this hungry world?

No more. :)

https://github.com/toml-lang/toml/releases/tag/1.0.0