Preserving order

[beygi]

we have a discussion here about preserving orders of hashes :
uiri/toml#2
its better to describe this in specification , my suggestion is : yes , key orders and group key orders must be preserved in parsers implementation

[mojombo]

I don't think preserving order in hash tables is necessary. It's a big extra step that implementations have to deal with and I don't see any compelling use cases. If you need ordering, use arrays.

[beygi]

preserving is necessary , for example i want to use toml as an operation config file and python parser should represent the keys in their original order in toml file so i can do actual jobs in correct orders , none of python implementations can do that because their represent a "dictionary data type" which is unordered , but php implementations are ok . in the other hand we cant create the same toml file with an output of a python parser because all hashes orders is wrong . its good to preserving the hash orders and its not a really big deal for implementations and couple of them such as php don't need to change . we fix one of the python implementation just now :) :

https://github.com/beygi/toml

[JavaScriptDude]

Just for posterity, the fact that it is called Table infers that it is ordered as tables are ordered. If its unordered it should be called a dictionary. I have heard several high visibility developers slamming TOML because of this exact ambiguity and they have vowed to never use it again, which I find silly but it happens.

Why not just start calling it a dictionary instead of table?

[eksortso]

@JavaScriptDude You're missing some context here. In JavaScript, objects are unordered by default. In Python since 3.7, dictionaries use insertion order, like Maps in JavaScript. In relational databases, tables are unordered by default.

The context matters, and in TOML the order of tables is said not to be guaranteed. That doesn't mean, though, that a parser can't provide an option to use the appropriate containers to enforce insertion ordering, so long as that behavior is documented. Such behavior is outside the scope of the TOML spec, but it doesn't violate the spec.

So, I must ask: in what context are tables, as you and your coworkers understand the term, ordered by default?

[JavaScriptDude]

I come from a perspective of intuitiveness where I originally got into programming after being an Lotus / Excel Guru way back in the day.

Wikipedia definition of table: "A table consists of an ordered arrangement of rows and columns".

I guess as long as the documentation makes it super clear in all appropriate places that a table is, for all intents and purposes unordered, that would suffice.

I do really like TOML and use it daily.

Here is one very high profile complaint that highlighting this issue: TOML's unstable table order made the team pop a couple ICs off the board searching for bugs .

[eksortso]

@JavaScriptDude Glad that you're getting good use out of TOML! Thanks for sharing your experience. I suppose "obvious" is a bold claim for us to make, but ultimately it depends on users reading the spec at least once, and on us making the important things stand out.

Also, thanks for sharing the complaint. I just now listened to that particular part of their presentation. They complained and hurled abuse at TOML, but the problems they experienced were all on them, because they assumed what they shouldn't have.

This issue is closed, so if you wish to suggest a way to guarantee in part that keys in a TOML document are ordered as written, open a new issue. We're in the process of getting v1.1.0 out the door, so it may take some time to revisit this. But I would welcome the conversation.