Introduce syntax for referring to current table in header.

[Jezza]

Problem:
As I was migrating a large config file for one of my systems to TOML, I noticed that I kept on having to refer to the entire previous key.

I think an example would explain the problem better:

[module.type1."this-is-an-id-that-is-really-long-and-annoying-to-read-because-its-conceptually-a-UUID"]
extra = "value"

[module.type1."this-is-an-id-that-is-really-long-and-annoying-to-read-because-its-conceptually-a-UUID".features]
something = false

[module.type1."this-is-an-id-that-is-really-long-and-annoying-to-read-because-its-conceptually-a-UUID".rest]
username = "asd"
some-key= "asd"

[module.type1."yet-another-really-long-id-but-shorter-than-the-one-before"]
extra = "value"

[module.type1."yet-another-really-long-id-but-shorter-than-the-one-before".features]
feature-flag = true

[module.type1."yet-another-really-long-id-but-shorter-than-the-one-before".rest]
extra = "value"

Bizarrely, it's not even much of a contrived example.
Particularly, for me, the features and rest table actually contain more keys and data, etc.

Solution:
Give us a syntax that's shorthand for "the previous section".
It'll cut down on the verbosity of it, and it won't suck when trying to pick between declaring another table, or trying to get away with making it a dotted key, or inline table, etc.

For a config language that's trying to remain minimal, I think this is gonna make things a lot easier to read.
Including arrays of tables.
I've had some people, both customers, and developers, complain about the way arrays of tables are handled, and I think this solution would actually solve both issues.

The syntax:

[module.type1."this-is-an-id-that-is-really-long-and-annoying-to-read-because-its-conceptually-a-UUID"]
extra = "value"

[.features]
something = false

[.rest]
username = "asd"
some-key= "asd"

[module.type1."yet-another-really-long-id-but-shorter-than-the-one-before"]
extra = "value"

[.features]
feature-flag = true

[.rest]
extra = "value"

It cuts down on a lot of boilerplate, and gets rid of the information you already have and know.
Where arrays of tables come in:

[[modules]]
value = "asd"
[.data]
something = "asd"

[[modules]]
value = "asd"

[.data]
something = "asd"

As I said before, a bunch of people have comment about how weird it is declaring a subtable for an array of table:

[[modules]]
[modules.data] # Not everyone sees the connection here...

They seem to be unable to associate the fact that it'll implicitly select the last value in the array, and add a table to that.
A couple of people thought that it's just a map with keys like 0, 1, and then data.

With this new syntax [.data], it'll already be established as the shorthand for "previous table", which for the case of array of tables, means it's a little less confusing.

This would also solve peoples issue with trying to avoid writing massive headers, such as in #516.
The third point is the fact that they don't wanna write long headers.
I agree.
For a lot of text, it can be annoying to read.

Personally, I think this would solve the issue, give us a lot of power without adding a crazy ground-breaking syntax, it's easy to add to a pre-existing implementation, and it's a quick addition to the spec.
Nothing massive is going to need to be rewritten.

[Jezza]

It's a bit of a ramble and all over the place, but I think the idea itself is good enough to warrant a discussion.

[ChristianSi]

@Jezza I'm not strictly against your proposal, but would point out that a nice and readable alternative exists already, namely, dotted keys. Using current syntax, your example can be rewritten as:

[module.type1."this-is-an-id-that-is-really-long-and-annoying-to-read-because-its-conceptually-a-UUID"]
extra = "value"
features.something = false
rest.username = "asd"
rest.some-key= "asd"

[module.type1."yet-another-really-long-id-but-shorter-than-the-one-before"]
extra = "value"
features.feature-flag = true
rest.extra = "value"

This is already quite readable and writable without requiring any new syntax.

[eksortso]

I like the notion of reducing really long header names in TOML. It's not a popular notion though, because long header names are typically easier to read and so are preferred for the sake of configuration. See #229 for the earlier discussion. That may change if TOML turns into a general data exchange format.

[pleroux0]

I would also like having a shorthand expression.

If the table names start to go off the edge of the screen, then it harms readability IMO. If there exists a table with a long name with a nested table with a long name, then the dotted keys format also become problematic.

[Jezza]

Another example in favour of the feature would mean things like this would be easier to read:

["some.annoying.id"]
metadata = "blah"

[["some.annoying.id".item]]
field1 = "value1"
field2 = "value2"

[["some.annoying.id".item]]
field1 = "value3"
field2 = "value4"

[["some.annoying.id".item]]
field1 = "value5"
field2 = "value6"

# Repeat another 15 times.
[["some.annoying.id".item]]
field1 = "value7"
field2 = "value8"

The repeating identifier really starts to drown out the useful part: item.

["some.annoying.id"]
metadata = "blah"

[[.item]]
field1 = "value1"
field2 = "value2"

[[.item]]
field1 = "value3"
field2 = "value4"

[[.item]]
field1 = "value5"
field2 = "value6"

# Repeat another 15 times.
[[.item]]
field1 = "value7"
field2 = "value8"

Granted, the "array of tables" syntax, isn't the most loved anyway, but the long header isn't helping.

EDIT: I also just realised, I actually already made this point in my original post...
It's been long enough that I'm getting the same ideas...

[ChristianSi]

An alternative – and very lightweight – syntax proposal would be to define [[]] as a shortcut for "repeat the last array-of-tables header". This would allow rewriting @Jezza's example as

["some.annoying.id"]
metadata = "blah"

[["some.annoying.id".item]]
field1 = "value1"
field2 = "value2"

[[]]
field1 = "value3"
field2 = "value4"

[[]]
field1 = "value5"
field2 = "value6"

# Repeat another 15 times.
[[]]
field1 = "value7"
field2 = "value8"

That's quite readable and relatively intuitive, I'd say.

[yyny]

[[]] could simply be an extension to the current proposal.
[] could also be added to be consistent, though it is pretty useless and might do more harm than good.

[pradyunsg]

The motivation here is to deal with deeply nested data structures. That's covered in #781, so I'm going to close this with the rationale that the approach discussed there will solve the underlying concern that this stems from.