The one thing I wish TOML had added was null. Today many TOML configs still have “nullable” keys which means you need to comment them out to unset them.
> There is a big difference between configuration language formats and programming languages.
You're right! But in my opinion the difference is that a configuration file should have a default state that could be written to disk and loaded with no change in behaviour.
eg you can set `feature = "on"` or `feature = "off"` and if you don't set either it's the same as writing `feature = "off"`.
Having a secret third thing of `feature = null` should be outlawed and I'm glad TOML doesn't encourage it
There is a secret third thing called "feature not in file" and most TOML implementation encourage it as "key not in file" is typically returned as `null` or `None`. That's how so many TOML files in practice end up with all these secret values.
It's also particularly odd in lists where I have seen `["foo", "bar", {}]` show up in the real world with `{}` being used as a replacement value for null.
In my experience (Python and Rust) missing keys are errors, not silently converted to None:
In [1]: example = {"foo": None}
In [2]: print(example["foo"])
None
In [3]: print(example["bar"])
---------------------------------------------------------------------------
KeyError Traceback (most recent call last)
Cell In[3], line 1
----> 1 print(example["bar"])
KeyError: 'bar'
In [4]: print(example.get("bar", "sensible default"))
sensible default
If configuration values were arbitrarily nullable I would either need to deal with the possibility of nulls ending up anywhere in my program (back to The Billion Dollar Mistake) or have to have checks on parsing to say which fields are nullable or not.
I acknowledge people have done silly things regarding missing keys already - but I think they should be discouraged from continuing to do so, not enabled.
> There is a big difference between configuration language formats and programming languages.
In general: I agree. But configuration formats (including TOML) also need to map well to programming languages, so you can't seem them as entirely separate. One argument against Null is that it doesn't elegantly map to a data structure in all programming languages.
> One argument against Null is that it doesn't elegantly map to a data structure in all programming languages.
TOML has plenty of constructs that don't map well to many languages. Plenty of language implementations do not know how to work with the datetime type, some TOML implementations barf on objects in lists. In some TOML implementations you also end up with nulls showing up when certain empty table constructs are used.
Making it map to every single language is always going to be hard, but most (mainstream) languages come with support for these kind of things in the language itself or standard library. That's not a good reason to add more though. It also pushes the complexity the complexity to the people using TOML in their programs, rather than the people writing TOML parsers: in some languages like Python or JavaScript you can "just" use a string and it's nullable, but in other languages you have to muck about with pointers, special types, options, etc.
Unfortunately that's not what `unset` does and I feel like the confusion it causes and the complication it adds to any CSS parser suggests it's a bad idea!
If you are referring to Tony Hoare, the “billion dollar mistake” was not the existence of nulls per se, but that all references were nullable, with no support in the type system to distinguish between nullable and non-nullable references.
I'm aware of the discussions. I also gave up trying to get NULL into TOML and I think I'm reference in one of those issues. Personally I do not create TOML configs where absence of key has a meaning, but I'm also exposed to other people's TOMLs where this is an actual issue with all the consequences this causes.
And that ignores the issue of nulls in arrays which are sometimes needed. For instance I have been exposed to parameterized SQL queries in TOML where you need to use the empty object to represent NULL, a particularly absurd incarnation of this.
I'm not saying there aren't reasonable and valid use cases, there obviously are. But there are also downsides, so the question is how it all balances out. Almost every feature that has ever been added to anything has reasonable and valid use cases, but clearly not everything should have all the features.
Null is one way to represent such a value, but it’s hardly the only.
Option-style algebraic types are another, and more or less strictly superior if working in a language with first class support for such, because they force you to explicitly handle the null/None/Empty/whatever case if you’re doing something with it that could fail (basically anything besides assignment or passing it along).
Seems beyond the simplicity TOML was aiming for. Absence is absence in the file, in your programming language you can wrap in whatever trickier you like or is relevant.
