Dotted key ordering isn't always preserved

[epage]

hello.world = "a"
goodbye = "b"
hello.moon = "c"

gets turned into

hello.world = "a"
hello.moon = "c"
goodbye = "b"

[epage]

If/when we add position information, a next step is to see if we can infer an inserted values position based on the parent dotted table. This would have us automatically organize new keys as is encouraged in the TOML spec

[ofek]

Has there been any progress on this?

[epage]

Generally, if there were, they'd already be posted here or in a linked issue

Overall, the use of dotted keys seems small and alt ordering being even smaller as its non-idiomatic, that this hasn't been a priority for me. If someone else wants to pick up the work, they are welcome to.

[ofek]

Thanks, I was just curious as I'm thinking about making Python bindings.

[fenollp]

Hi! Drive by question:
What/where is the struct or tree holding the collection of values dotted and otherwise and how can we make that type and its underlying values types "sort" in insertion order?

[epage]

As this is isn't a focus area / priority of mine, it will be up to you to do some leg work on investigating this.

[crazymerlyn]

Looked into it and the cause seems to be the recursive way the the structure is stored. KeyValuePairs is an IndexMap so it should already maintain the order. But for dotted keys, hello.moon's top level key is just hello, the same as hello.world. As a result, when traversing, hello.world and hello.moon are bunched together before goodbye.