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