[hallway_monitor]

Your statement is false. Many use cases call for optional bools. The great thing is there is no implicit meaning - it's True, False or Unset. It is true that nulls can be abused but in this case, far more elegant than an enum.

[alpaca128]

There is no way for you to make sure that `null` was "set" intentionally and not due to a bug or other kind of failure.

Meanwhile if you see a `None` value you know for a fact that it was set by your software and if you actually encounter a `null` you know that something went horribly wrong.

Strong type systems and a few overheads in favor of better bug detection/prevention are popular for a reason.

[samhh]

There are many application states in which `null` could mean "not got the data yet" and/or "there is no data".

Just use an enum, it's much more expressive.

[Dah00n]

Could you supply an example that an enum wouldn't do as well? How is a bool null, false, true different than an enum with null, false, true?

Edit: grammar

[samhh]

Logically they're the same, they're isomorphic. It's just about ergonomics, readability, etc.

[ThinkBeat]

If you go with nullable Boolean in the database schema, do you give it a type of nullable boolean in the code?

In which case null would either mean the value on the recordin the database is null, or that that for whatever reasons that parameter was not read from the database.

You will need two types of null.

All of this goes away with an enum or similar solution.

You can decompose the nullable boolean in the database when you read it , but again your task would be easier to treat it like an enum.

[swaggyBoatswain]

I use nulls or undefined in javascript as the initial state for most values for this reason, it's explicit in that it's unset

Ditto for database design too