I've made my own config format precisely because TOML was not good enough. But INI would have been worse for my case. Strict typing is good. If you expect a nu

I've made my own config format precisely because TOML was not good enough. But INI would have been worse for my case. Strict typing is good. If you expect a number, and it doesn't parse, you want to know that. Strict typing communicates intent. And that is worth gobs of effort. (I do admit that the author has a point about times when apps just want a string value, so I think I'll add a function to get the string value of a move no matter what type it is.) Also, as much as the author slams TOML's avoidance of ambiguity, the industry has learned that Postel's Law is bad. We need to be conservative in what we emit and accept, for several reasons, the most important of which is that parsers are some of the most dangerous code; any possible ambiguity could be a security bug or many waiting to be discovered. My parser is opinionated because that prevents bad things from happening. The author is also wrong about C not handling mixed arrays well; my config format is JSON with a few niceties, and I easily implemented it in C, even though it can have mixed arrays. And braces/ brackets in JSON are not human-editable? Come on... That said, some changes to JSON were necessary to make it easier to edit; besides comments, I also added keys that don't need quotes, as long as they are one word.