What would you remove from TOML to make it perfect?

weinzierl 17 hours ago | parent | next [-]

Tables.

Not 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.

	▲	PunchyHamster 16 hours ago \| parent [-]
		Tables in TOML have uniquely bad format

▲

kibwen 17 hours ago | parent | prev [-]

All 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.

▲

drdexebtjl 16 hours ago | parent [-]

The problem is that you end up with multiple dialects, just like INI.

For 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.

	▲	kibwen 11 hours ago \| parent [-]
		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.