>>29could
would
You're sounding like a Lisp wizard. I've written C# and it was a fucking pain to keep track of what was and wasn't checked for null, with runtime errors constantly surprising me. The compiler can't help when the language's type system is compromised by the billion dollar mistake.
How is your code structurally different from, say, this C code:
In C you can write:
void foo(result) {
if(result != NULL) { // We can't omit the check here because there's no guarantee
...; // foo is always going to be called with non-NULL arguments.
}
}
if(result != NULL) // We check for NULL because we can't be sure foo will be doing that.
foo(result); // ...and that's a superfluous double check the type system didn't prevent.
else
...;In those other more modern languages, on the other hand, you
have to pattern match the Some/None on
Option(Item) (ie. handle the case of the null painter) and you
can't do that pattern match on
Item. It's a tight correspondence which both gives correctness and prevents unnecessary performance degradation.
The point is, like I said, that there's a distinction on type level between nullable variables (
Option(a)) and non-nullable values. That is a benefit of using sum types (you know, like C unions but done right), yet there are many more.
And 'forgetting' the NULL-check here is almost impossible when it's a linked list traversal
It's far from impossible in practice. Let's say the linked list is the result of a function called on the result of another function that handles various IO-related cases where one of many possible information sources may be used. In a complex code tree it's hard to keep track of where and in which code paths you remembered to check for null. It's either going to be amnesiac programming like in my example above, or null pointer exceptions biting you in the ass at runtime. The saddest thing is that it might seem you've gone full amnesiac but it still fucks up at runtime because there's still some obscure code path that you haven't covered in testing.
Null pointers are such a pain in the ass with such a clear solution that I don't see how anyone could argue they have benefits when even the creator of Java admitted them as a billion-dollar mistake.
they shifted the security check from the programmer to the library implementor
First of all that is a great thing because libraries are supposed to be heavily-verified, ready-to use pieces of code. Not reinventing the bicycle and all that. Secondly, you'd have to jump through some hoops to avoid
Option when defining linked lists because linked lists are by nature sum types and the only way to deconstruct a sum type is through pattern matching, and that's when the compiler checks for exhaustiveless (ie. that all cases were handled). If you're trying to write the iterator as returning a non-nullable item, then what item are you going to return in the None branch?
fn next(&mut self) -> Self::Item {
match *self {
Cons(x, xs) => x,
Nil => ???,
}You see, pattern matching is this beautiful concept because it balances creation of data structures with their destructuring. For every layer of wrapping you add, there must be a procedure of unwrapping that layer. The handling of failure cases (of which
Option is just the simplest example) comes as a byproduct of that Yin-Yang balance.