4 ms·

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.

Guthur 3y ago
Well that would be null right? an absence of the thing.
- TylerE 3y ago
  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).
  - Guthur 3y ago
    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.
    - TylerE 3y ago
      The trick is distinguishing empty string vs no value vs key not being present.
      - Guthur 3y ago
        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.
        TylerE 3y ago
        It’s that “or” that bites you if you aren’t real sure of the semantics in play.
        Guthur 3y ago
        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.
lexicality 3y ago
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_mitsuhiko 3y ago
  > 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.
  - lexicality 3y ago
    > 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
    - the_mitsuhiko 3y ago
      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.
      - lexicality 3y ago
        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.
arp242 3y ago
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/921 https://github.com/toml-lang/toml/issues/803 https://github.com/toml-lang/toml/issues/803 https://github.com/toml-lang/toml/issues/802 https://github.com/toml-lang/toml/issues/802 https://github.com/toml-lang/toml/issues/146 https://github.com/toml-lang/toml/issues/146 https://github.com/toml-lang/toml/issues/30 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.
- the_mitsuhiko 3y ago
  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.
  - arp242 3y ago
    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.

Guthur 3y ago

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

TylerE 3y ago
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).
- Guthur 3y ago
  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.
  - TylerE 3y ago
    The trick is distinguishing empty string vs no value vs key not being present.
    - Guthur 3y ago
      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.
      - TylerE 3y ago
        It’s that “or” that bites you if you aren’t real sure of the semantics in play.
        Guthur 3y ago
        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.

lexicality 3y ago

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_mitsuhiko 3y ago
> 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.
- lexicality 3y ago
  > 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
  - the_mitsuhiko 3y ago
    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.
    - lexicality 3y ago
      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.

arp242 3y ago

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/921 https://github.com/toml-lang/toml/issues/803 https://github.com/toml-lang/toml/issues/803 https://github.com/toml-lang/toml/issues/802 https://github.com/toml-lang/toml/issues/802 https://github.com/toml-lang/toml/issues/146 https://github.com/toml-lang/toml/issues/146 https://github.com/toml-lang/toml/issues/30 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.

the_mitsuhiko 3y ago
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.
- arp242 3y ago
  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.