It’s been debated many times before and there’s some validity to the theory of not using null, but it becomes easy to overthink ways to avoid saying something doesn’t exist, when it truly doesn’t.

When I was learning to rewrite Apple apps in Swift, I came across the best practices of the language around nulls in particular that they were pushing at the time. They were trying to make programmers not use null, but they also gave the ! and ? operators to work around code that uses it. Naturally, if you’ve been using null for years or even decades in every language you’ve previously used, you’re going to fall back into habit when you find situations that make it hard not to use it. Especially when you want to avoid making a simple issue convoluted.

The Optional<T> would be more explicit and clearly defined, but is a bit more cognitive overhead to understand. I guess I can see this overhead paying off if it actually prevents more careless mistakes or oversights. I can see there being value in that.

Then inventor of null might have been too hard on himself though. I’m sure if he invented Optional<T> instead, people would still find some way to write buggy logic around it.