#WHY??
1 messages · Page 1 of 1 (latest)
https://www.gingerbill.org/article/2026/01/02/was-it-really-a-billion-dollar-mistake/
tl;dr nil pointers are the least of your concerns in terms of things that can go wrong when it comes to pointers 🙂
but still it makes it not clear if the value returned by this fn is guaranteed to have a valid reference and checking every single one of them is annoying
most of nil pointers are bugs anyway
Odin also has the -> (res: ^T, ok: bool) pattern which is more ergonomic than checking the pointer
also, just don't return pointers
it's not that hard
would you not being doing that with an optional type anyways? either you check it, or something does for you.
the thing is if its not wraped in optional i can know for a fact that its valid if its not nullable
this is exactly why pointers shouldn't be nullable by default
nil pointer dereference is the easiest bug to spot and fix
In any case, the language's semantics pretty much don't allow them to not possibly be nil. ZII/zero is initialized; everything is default-initialized to 0
having non nil pointer will literally solve nothing and make the language much more clunky to use
(since odin is not designed to be memory safe)
i think you are being unfair in using a language not even one day and then throwing yourself at the debate about its core design
that is what Maybe(^T) gives. unions who only have a pointer in them drop the tag, and the tag check becomes a nil pointer check.
-# it still might not be valid memory, but that's besides the point.
wait does that mean every language that allows zero initialization has a secret null value
I think you are right i will read the article then