matklad / tom

tom: a format-preserving TOML parser in Rust
Apache License 2.0
38 stars 2 forks source link

How should different table types interact? #19

Open ehuss opened 6 years ago

ehuss commented 6 years ago

I added dotted keys to toml-rs and I have a lot of uncertainty about how different table types should interact, and I wanted to see if you had any thoughts on the matter (and how it works with tom).

There's a lot of discussion ([1] [2]) about whether header tables, inline tables, and dotted key tables should be able to affect one another.

For example, can header tables and inline tables modify one another?

a = { b = 1 }
[a.c]
d = 3

Some TOML implementations allow this, some (like toml-rs) do not. What do you think?

matklad commented 6 years ago

Hm, so I tend to think that this is unfortunately underspecified in the current TOML spec.

I've once was sure that it is invalid toml, because the a table is defined in full, so we can't append to it. But then https://github.com/toml-lang/toml/issues/446 should some examples which are valid toml, and which I, using this rule, would classify as invalid. So, my understanding is wrong.

For tom specifically, we can actually punt on it a bit: strictly syntactically, this is a valid toml, the error is semantic.

We handle semantic errors in the validation phase here: https://github.com/matklad/tom/blob/06476b29de9e93fe435ab1feb7fef7d9e2869ce3/src/validator.rs. Such semantic errors don't stop further processing, the rest of the library is totally fine with such invalid documents.

So, for us, I think a reasonable thing to do would be to go with conservative route, treat it as an error in validation, produce an error message, but support when building a semantic model. That way, consumers of the library can for themselves decide if we want to ignore the error, or to bail out.