The limitations are mainly around nested arrays of tables. As has been mentioned here already, the [[array-of-tables]] syntax that currently allows this can be super confusing, and is definitely the worst part of TOML right now. Even so, you can often work around this weakness by reworking your config file to pick up on a specific naming scheme (perhaps every "server-*" table is interpreted as a member of an array) or maybe there's an array of strings that contains the names of the tables, each of which becomes an array member in that order. But these are hacks, and it would be nice to have a first-class way of dealing with nested large tables that was easy to scan and not too repetitive.
That said, the alternative right now in other formats is basically a { bunch { of { braces } } which is also not the most amazing thing for long nested tables.
> The limitations are mainly around nested arrays of tables. As has been mentioned here already, the [[array-of-tables]] syntax that currently allows this can be super confusing, and is definitely the worst part of TOML right now.
Good to know this is recognized. Looking forward to a better syntax to an indeed difficult problem
is this e.g. due to the verbosity of re-declaring field names every time? or something else?
e.g. CSVs handle 2D tables reasonably efficiently, since you just specify values:
field_a, field_b, field_c
1, 2, 3
3, 4, 5
but I imagine TOML would benefit from something that lets you define nested tables without re-defining the table every time... which probably conflicts with the "obvious" goal. Hmm.
That said, the alternative right now in other formats is basically a { bunch { of { braces } } which is also not the most amazing thing for long nested tables.