My case for null

[Lordfirespeed]

Motivating use-case 1

I come from the JavaScript ecosystem where we have a package called config.

I really like the pattern it implements. I end up setting up my projects like this:

.
├── config
│   ├── .gitignore
│   ├── default.ts
│   ├── local.ts
│   └── production.ts
├── package.json
└── src
    └── ...

Now,

• default.ts contains a complete 'development' configuration, and is included in VCS.
• production.ts contains a partial configuration of overwrites that are applied conditional on the NODE_ENV environment variable, and is included in VCS.
• local.ts contains a partial configuration of overwrites that are always applied, but is not included in VCS.
• The config library will deep-merge the structures exported from these files in a consistent, predictable order.

In practise, this is good for various reasons ...

• default.ts acts as living documentation for the overwrite keys I can choose to add to local.ts, production.ts.
• I don't have to repeat myself or remember to copy things from default.ts to production.ts when I make changes.
• I can specify machine-specific configuration in local.ts without affecting collaborators.
• I can store sensitive credentials in local.ts without exposing them via my VCS.

Notably, though, for this pattern to work, I sometimes need to use null or undefined values in production.ts in order to 'unset' values defined by default.ts.

So when I came to trying to implement this pattern for a Python project using .toml files in place of .ts, I was fairly dismayed when I found out I can't have null values in .toml files!

Motivating use-case 2

Say I have an 'optional' value which I load from a .toml file.

foo = "bar"  # foo can be omitted
baz = "qux"

As long as the defined value for foo is not null-ish, it is obvious to any contributor to my project simply by looking in the config file that they can amend the value of foo to have some effect on the project's behaviour.

But if the defined value for foo is null-ish, I can either

• Comment out the line
• Omit foo from the config file

Both of these make it considerably less obvious to an arbitrary individual that foo is something they can amend the value of.

Other remarks

null and undefined are simply 'sentinel' values roughly meaning 'the absence of a value'.
If we want to get really silly, we could say TOML already supports null-ish values ...

Strategy 1: 'flags'

foo_is_null = true
foo = "bar" 

baz_is_null = false
baz = "qux"

foo -> null because foo_is_null
baz -> "qux" because not baz_is_null

Strategy 2: bring your own sentinel value

select an arbitrary value that is unlikely to ever show up in common use ...

$ openssl rand -base64 48
7HPoQeiEIN8cE+hgW71KoiWCYDGM9DwKcF1fCVGDF0jZQbn5iEeBzLxYR5gK0LkR

and use it to represent null values

foo = "7HPoQeiEIN8cE+hgW71KoiWCYDGM9DwKcF1fCVGDF0jZQbn5iEeBzLxYR5gK0LkR"
baz = "qux"

foo -> null because its value is exactly the chosen sentinel value
baz -> "qux" because its value is not the chosen sentinel value

fin.

since null-ish values are clearly 100% supported already (/s), what difference does adding a null keyword make? it would save people the effort of running openssl or duplicating all the keys in their files :0)

I want to be arguing over null/nil/none/undefined, not about whether TOML needs null!

[johnchristopherjones]

Part of your first use case is perplexing. If you "unset a default", then you have no default value.

I believe what's implied is that there is, in fact, another layer of defaults below default.ts. Let's say you're merging like this:

[real_defaults] <- [defaults.ts] <- [local.ts]

You could describe what you're doing as either:

• setting a value in local.ts to "whatever is in real_defaults" by using a singular magic value; or
• conditionally bypassing default.ts.

In either case, it seems more like an artifact that emerges from your merge strategy. The simplest solution to me seems to be don't set it in "default.ts" in the first place). It's also a really common convention to generate "default" configs with some options commented out to indicate that you can can override them, which you could do here with default.ts. I don't think commented-out options make their availability "considerably less obvious", but JSON doesn't support comments, so perhaps it is more surprising for people who don't expect comments to be valid in config files.

[Lordfirespeed]

you're wrong. there is no layer below default.

If you want to be pedantic, fine: you can interpret my case as having real_defaults where all values in that layer are null-ish.

When I say 'unset a default', I mean 'set a value defined in default.ts to some null-ish value'. This makes sense, because almost every programming language ever has a runtime representation of null or similar; why should it be impossible to specify that value explicitly using .toml?

Say we are (hypothetically) designing a language for representing numeric values. Should we represent zero as 0 or should we disallow that, and interpret only the lack of a value as zero?

You're right - using the current toml spec, not setting defaults at all is the only way of doing things.
However, I described in detail the reasons I do not want to do that.

Your particular opinion about the obviousness of commented-out values is of little relevance, because I disagree, and others do too; the prevalence of those people does not matter, only that they exist.

JSON does not support comments. .ts (typescript) does.