Maybe(^T)

And in practice, you rarely have to defensively check for nil pointers in practice, especially since Odin has very different semantics to C. When writing Odin, you rarely in practice write pointers due to type inference (which solves the initialization problem), multiple return values (removes the need for out-by-pointer parameters), immutable procedure parameters (allowing for const reference semantics), and many other wonderful features.

Lastly and empirically speaking, nil pointers are the easiest class to catch in practice compared to other invalid memory addresses, especially due to virtual memory protections on the first few pages. People focus on the nil pointer "problem" since it's effectively a drunkard's search problem nowadays.

https://teddit.net/r/programming/comments/x0lmyo/why_i_like_odin/imadeic/

Nullability's more interesting in a language like Kotlin. In a language with manual memory management you have many potential mishandlings of errors and de-referencing NULL is the least scary of them.

See also:

• https://digitalmars.com/articles/C-biggest-mistake.html (it isn't NULL)
• gB interview, starting at his telling of the drunkard's search