[DarkNova6]

I think this is about 2 problems coming together:

- 1: In C (and relatives), you cannot rule out that any pointer is not-null. Simply due to pointer arithmetic.

- 2: Some values have no default-zero state.

On #2 I found the EG discussions on the Java mailing lists to be fascinating. Think of innocuous types such as "date", where a default value only causes problems. You end up with something like "1970:0:0" or "0:0:0" and it acts like a valid date, but its use is likely unintentional and leads to follow-up issues.

And once you have multi-threading involved, even a simple null-flag becomes a difficult technical challenge to implement under all conditions.

[K0nserv]

While null-pointers are possibly under #1 it seems much more likely that you'd produce other kinds of invalid pointers(out of bounds, unaligned etc) than nullptr. The use of null pointers to signal absence and failure is surely the most common source of them in C (and relatives).

I've always understood the billion dollar mistake to be more about #2 and language like Java in particular. Agree about default values being bad, it's one of my primary reservations with Go.

[DarkNova6]

> While null-pointers are possibly under #1 it seems much more likely that you'd produce other kinds of invalid pointers(out of bounds, unaligned etc) than nullptr. The use of null pointers to signal absence and failure is surely the most common source of them in C (and relatives).

Fair point. Still, it just leaves a bitter taste when you want to express something as non-null but can't technically exclude it...