[jeroenhd]

I've seen some terrible implementations in Java abuse Boolean as a tri state value: true, false, null.

However, this always caused bugs because you'd end up with terrible code patterns. For one, what does "unset" mean? Does it equal false, because it wasn't enabled? What's the default? I think "unset" is a state to be generally avoided because it's bound to create problems for you down the line.

Personally, I prefer enums for anything that's not an actual boolean. A boolean should, in my opinion, always be a yes/no variable. Other states should probably be more specific.

I've seen people use booleans and other types to represent limited options (i.e. animal.IsCat to determine if an animal is a cat or a dog. I'd go so far as to create enums that will only have two or even just one option if expansion is expected soon enough, with an optional state encoded in the type system as well. If your database can't store optional/maybe values, I'd add an enum variable.

Of course I'd make an exception if you're terribly resource constrained. If you need to save every bit, document the hell out of it and optimize your code any way you want.

[dhzhzjsbevs]

> For one, what does "unset" mean? Does it equal false, because it wasn't enabled? What's the default?

This is a common strawman used to advise against null.

Null only means one thing. Null. It doesn't convey any further meaning. It is a "not set" or "not initialised" state.

It isn't a default, it isn't false, it isn't not enabled.

If you have a user interface tied to this variable. Null means not yet set.

This is entirely logical. The only people getting their knickers in a bunch are those that don't want to admit there is uncertainty and context required to determine what null means in your application.

My advice: don't apply further meaning to null other than null or not set.

[sumy23]

I think people are conceptually fine with null. What they’re annoyed with is the inability to know if null is a possible value for a variable in many programming languages, e.g. Java.

[dhzhzjsbevs]

I understand this but just basic code hygiene of null checking at boundaries and edges makes this a non issue.

You shouldn't be setting nullable variables to null so far away from where they're used that they're a problem.

E.g. if you're passing around an object with a possibly null value attached you should instead set it to a default empty state, empty string, zero, false etc.

Its only in rare circumstances that you should be needing to worry about null values.

I will however concede that non nullable types are super useful. I just don't think languages should remove null entirely. E.g. some rust projects have so many options types null would have been easier to code around. I know this is down to inexperience but at that point you've lost me - inexperience with null types is the only thing that makes null types a big problem.

[unsafecast]

Indeed. Optional values are literally the same as null, but you know that it _can_ be null.