3 ms·
That's already fixed; in the upcoming TOML 1.1 you can write: tbl = { hello = "world", } All the examples in the issue you linked should work. https
by arp242 3y ago
That's already fixed; in the upcoming TOML 1.1 you can write:
tbl = {
hello = "world",
}
All the examples in the issue you linked should work.
https://github.com/toml-lang/toml/pull/904 https://github.com/toml-lang/toml/pull/904
- bdudbdjsh 3y agopublished data standards having version is so wrong. now if you see "config in yaml" you know nothing, zero, nada, about the format because all versions are so different and everyone implemented the version at the time and didn't bother to mention version. not to mention you can use a dozen syntaxes for yaml/toml and each application may not understand them all. all this is so silly. we will stick with json and informal-ini forever one way or another.
- eviks 3y agoSince it's impossible to design anything great in tech on first attempt, what is the road to improvement without versions? (and mentioning version could be a requirement in a future version)
- arp242 3y agoIt's not ideal, I agree, but it solves real problems for people, so there's that. Many commonly-used standards today weren't created by a bunch of wise men in a room thinking how to bestow their wisdom upon the rest of us, they often originated in real-world applications, were refined over a period of time based pn real-world experience, and then became a standard. TOML is the same. I hope it will become an RFC some day. We just need to fix a few outstanding issues first. Most commonly used TOML parsers support 1.0; adding 1.1 support should be pretty easy as the changes aren't that large (I did it in the parser I maintain, and it's 10 lines of code or so that had to be changed, most of them quite trivial).
- Marazan 3y agoMy opinion is that having a version is fine buy only if a version field is built into the spec. Without that your config file is a boobytrap, with it everything is fine and your parsing libraries can even be backwards compatible.
- ruuda 3y agoAnd if you have to version it, Kelvin versioning is more appropriate for standards.
- isitmadeofglass 3y ago[dead]
- SPBS 3y agoThe is great news, thank you for your work on this.
- IshKebab 3y agoHow do you know which version you are using though?
- arp242 3y agoYou don't; you check the library or application's documentation. TOML went through some substantial changes in the past with 0.4, 0.5, and 1.0. As I mentioned in my other comment[1], it's not ideal, but it is what it is. I wouldn't be surprised if 1.1 would be the last version. Maybe there will be a 1.2 to clarify some things, but I wouldn't expect any further major changes. [1]: https://news.ycombinator.com/item?id=36020654 https://news.ycombinator.com/item?id=36020654
- IshKebab 3y ago> You don't Great. Very obvious.
- josephg 3y agoAs much as it pains me to say so, this is probably fine for configuration languages so long as they’re backwards compatible. Eg toml is used by rust’s cargo tool. Cargo can just say “hey Cargo.toml is parsed in toml version 1.1 format”.
- IshKebab 3y agoHow does your IDE and linter learn that? In fairness it's probably not too bad as long as everyone actually migrates to the newest version eventually... But that isn't guaranteed - look at YAML. Or even JSONC. VSCode has a hard-coded lists of which `.json` files are actually JSONC. Gross.
- afiori 3y agoYAML is way more complex and JSONC is not JSON 1.1