Enforce constraints

[ordian]

Problems

1. Currently, toml spec does not have any positional constraints on tables (cf toml/issues/446). E.g. this is a valid toml:

[[bin]] # bin 1
[a.b.c.d]
[a]
[other.table]
[a.b.c.e]
[[bin]] # bin 2
[a.b.c]
[[bin]] # bin 3

This greatly complicates internal design of toml_edit, e.g. we have to store this order somewhere outside of the tables (document), and in order to support table insertion and deletion on Table, we have to store a pointer to the document in it. That's why we don't allow a user to own a Table, providing only a (mut) ref to a Table.

If we are free to reorder the tables when printing them, we can simplify the design and get rid of the no-ownership constraint. This, in turn, would allow us to have a single Value enum and implement serde_json-like nice API and get rid of unsafe code!

2. Another annoying thing is whitespaces in headers.

[ 'this  '   . is . a .valid.    "header..." ]

In order to preserve this layout, we have to store the whole header in the Table, but then Table assignment would be unfortunate, because header will also be mutated, while in hashmap, storing subtable index, there still be the old key.

Proposal

1. Allow any order when parsing the document, but internally store all children after theirs parent. Also store array of tables in one place. When printing the toml from above, it would look like:

[[bin]] # bin 1
[[bin]] # bin 2
[[bin]] # bin 3
[a]
[a.b.c]
[a.b.c.e]
[a.b.c.d]
[other.table]

Unresolved: should we sort the children as well?

2. Drop all whitespaces in the header.

['this  '.is.a.valid."header..."]

cc @killercup, what do you think?

[killercup]

I'm totally fine with this being a… let's call it "intention-preserving pretty printer" :)

At the last rust.cologne meetup, we talked about a more simplistic approach to a toml reader/writer specifically for cargo-edit. One design we landed on was Having the whole toml AST consist of slices of the input string (maybe represented as rope). Adding/removing an entry would then "just" be inserting another slice at some position, or removing slice(s). I doubt this scales well to a more general purpose library, though.

[ordian]

Thanks for the feedback!

I think I've got an idea on how to improve API without implementing this proposal. As for duplication in Table and InlineTable, a viable approach worth investigating may be to create a common trait TableLike and implement a method on them, which will return a trait object.

I'm going to close this issue.