Tables.
replyNot from TOML, just from my config language. TOML has other applications that require its complexity.
I'd still keep simple INI style sections in my config lang, but they wouldn't have deeper meaning apart from grouping.
Tables in TOML have uniquely bad format
replyAll scalar types other than strings (especially nonsense like datetimes). I'm already ingesting the configuration file as a string and parsing it into a language with actual types, e.g. Rust, and the act of parsing it into my defined configuration type will itself identify any problems with the config; having half-assed types like "int" in the config file format itself is not only useless, it's counterproductive because it requires people to ask questions like "okay, but what actually is the maximum range of integer values allowed to be contained in this type?". Just enforce UTF-8 encoded string values and let me take care of data validation.
replyThe problem is that you end up with multiple dialects, just like INI.
replyFor example, I’ve seen booleans being represented with “enable”/“disable”, “yes”/“no”, “t”/“f”, “1”/“0”. Sometimes a mix in the same program.
It’s nice that every TOML config requires “true”/“false” across any application.
You won't end up with a mix in the same program unless the code that you're using to parse the config is deliberately written to allow a mix, which no sane code owner would allow. And even if it did, that still wouldn't be enough to outweigh the aforementioned downside of the impedance mismatch between the """types""" in your config file format (how many bits wide is this integer? how much precision is this float? how is nullable data represented?) and the types in your actual language where it matters.
reply