Clarify key name syntax.

[mojombo]

After reflecting on the matter of key names for quite a while, and taking into consideration the many opinions in #65, #67, #220, etc, I've changed my mind on how I think they should be specified. This PR proposes two types of keys: bare and quoted. Bare keys are extremely restrictive [A-Za-z0-9-_]+ while quoted strings can contain almost anything. I like this approach because it is easy to understand (and remember) and guides users to choose simple key names while still making complex names possible. This proposal should also make the parser's job very simple and eliminate any weirdness that could come from having to deal with undelimited Unicode.

cc @wycats, @BurntSushi, @ChristianSi

[ChristianSi]

"letters" should be "ASCII letters" ('Ä' is a letter too).

[BurntSushi]

I very much like this!

[ChristianSi]

I made a little line note, otherwise this looks good 👍

[redhotvengeance]

👍

[BurntSushi]

@wycats @alexcrichton do you have any thoughts on this? Will it cause any major churn in Cargo.toml? Unquoted keys allow for - and _, which I know a few packages use, so that's good I think.

(For others: Cargo is Rust's package manager, and it uses TOML as its configuration format. If they aren't already the biggest users of TOML, I'm assuming they will be soon. So I think it's good to check with them before we make backwards incompatible changes.)

[mk-pmb]

👍 although a lot of my .ini files won't be valid TOML anymore.

[alexcrichton]

Bare keys being so restrictive was somewhat surprising to me, but I think we're fine on Cargo's end. I believe we currently have the exact same restrictions on package names (which can be used as a bare key), and all other keys are basically the same.

This sounds like a great idea, and thanks for the heads up!

[flaviut]

👍, although in the interest of compatibility with existing ini files, I'd also like clarification on how #220 (comment) should work.

[mojombo]

@flaviut As much as I'd love for TOML to be somehow compatible with INI files, I don't really see it happening. Since inception, TOML has diverged from INI (if that's even possible, given the non-standardization of INI), and we must make choices that are right for TOML even if that means giving up on the dream of TOML-as-superset-of-INI.

[mojombo]

I believe we currently have the exact same restrictions on package names (which can be used as a bare key), and all other keys are basically the same.

@alexcrichton Sweet. I'd love to verify that, just to make sure TOML will continue to be easy to use for Cargo. Think you can take a look and see, or point me to the proper place in the Cargo source? Thanks!

[alexcrichton]

Think you can take a look and see, or point me to the proper place in the Cargo source?

Sure, this is actually validated in our registry, crates.io, when crates are published.

[mojombo]

@alexcrichton Excellent, thank you for checking! Do you know if @wycats is around? I'd love to have him weigh in before I merge this.

[wycats]

@mojombo I think the biggest issue here is that ünicode-crate = "1.0" (which we don't support now, but could) would require quotes. I don't think the quotes are such a big deal, but would they be expected?

What do you think?

[mojombo]

@wycats Yes, with this PR you'd need to specify "ünicode-crate" = "1.0". Idealistically I'd love to support unicode in key names, but I think the complexity and ambiguity is just too much to make it worthwhile. Quoting lets a reader know that something unexpected might be going on in the key and force them to look twice, reducing unnecessary confusion and mistakes.

[mojombo]

I'm going to merge this PR, as I strongly believe it's in the right direction. If we need to tweak it, we can do so in another PR. Thanks for the feedback, everyone. One step closer to 1.0!