"Unexpectedly found nil while unwrapping an Optional value"

What dev thought this would be a good idea in Swift? Sometimes I hear the compiler's thoughts as it comes across this:

1. The dev explicitly told me this value would be optional.
2. I have a record from the database, and I see a 'nil' in the column for this value.
3. That's not "None" , Oh my god, I need there to be an explicit "None<CustomType>".
4. Shit shit shit shit. Oh my god.
5. PANIC!

While there are use cases for distinguishing between the empty set and the unknown set, most often a single unit type is enough and having more than one really makes anything written in the language just slightly less maintainable.

JavaScript has the same problem with its undefined and null.

It's great when you don't have to check for nulls because it means there can't be any, not because you save a few commands.

Null isn't the same as Option::None; it's a sentinel value which is implicitly assigned to everything, and which can mean anything but most of the time it just means that whatever should have populated the field failed to do so. In my opinion, null should produce a recoverable error in any scenario except a null check, even in an equality comparison, which is not the same operation semantically so it should not be the same operation syntactically.

When you don't have to check for nulls, that's great—not because you save a few commands, but because it means there can't be any. https://basketball-stars.co/

@lorentz I totally agree, None has intention null does not.

I have started to use the new nullable reference type in C# and it really removes a whole category of runtime errors and breaks on compile, which makes it much easier to solve.

How often have we not tried to find the cause for that occasional null reference error just to find that some one used null for empty but later code just assumed there would always be a result.