Hacker News Reader

Comment by the_mitsuhiko | Hacker News Reader

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.

View on HN

The Billion Dollar Mistake lives on.

Personally I'm happy it doesn't have explicit null and somewhat surprised it supports NaN (which I thought it didn't)

To my mind, a configuration file using "this key doesn't exist" as one of several valid options seems deeply unsound.

> The Billion Dollar Mistake lives on.

I disagree. There is a big difference between configuration language formats and programming languages.

> To my mind, a configuration file using "this key doesn't exist" as one of several valid options seems deeply unsound.

I would agree, but in that case you now often need a secondary key to "turn something off" which is often not done.

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

How is checking for null any different than checking for the right type in general in TOML?

> In my experience (Python and Rust) missing keys are errors, not silently converted to None:

In Rust it's possible to deserialize to an Option.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

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

> Plenty of language implementations do not know how to work with the datetime type

Right, and IMO datetime was a mistake to include in TOML.

CSS has two magic values that would be useful in many configuration scenarios:

- unset: ignore values of this property

- initial: use the default value

These would be useful e.g. with overrides.

I agree that nulls in a config files are often not a good idea because it is not clear how they are going to be interpreted.

PS: Css also has inherit that could mean "use the local default" while initial could mean use system default.

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!

lol, I guess this might be an argument against null

Still, initial and inherit are good things to have.

They are about as useful in a configuration language, where the cascading logic also applies.

> The Billion Dollar Mistake lives on.

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.

It's been discussed a few times over the years:

https://github.com/toml-lang/toml/issues/921

https://github.com/toml-lang/toml/issues/803

https://github.com/toml-lang/toml/issues/802

https://github.com/toml-lang/toml/issues/146

https://github.com/toml-lang/toml/issues/30

Obviously there is a bit of a demand, and it certainly has valid use cases, but also has downsides.

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.

Well that would be null right? an absence of the thing.

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.

The trick is distinguishing empty string vs no value vs key not being present.

Key not being present is no value, key present has value, empty string or otherwise, seems simple enough.

You can add advanced semantics on load, the file does nothing by itself after all.

It’s that “or” that bites you if you aren’t real sure of the semantics in play.

There is no 'or' for a given file, it is declaratively there or it is not. The 'or' semantics are part of your language environment not the toml file.

Reply on news.ycombinator.com