To be or not to be, that’s an Option!
Many programming languages have the feature where they intend to depict a Null. Null as a value conveys that either it is currently invalid or currently unavailable. Such a state is important in a programming language. It’s a perfectly valid use case to convey the validity of a value. But still, the inventor of Null, Sir Tony Hoare said this about Null:
I call it my billion-dollar mistake. At that time, I was designing the first comprehensive type system for references in an object-oriented language. My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
One of the easiest mistakes you can make in a Null intensive situation is that you may assume a value to be not null and it turns out to be a null. Such a situation produces errors, exceptions, segmentation faults and what not. So to be fair, the idea of having null is fine, its implementation, however, can produce unwanted pitfalls.
Rust, as a matter of fact, doesn’t have NULL. But despite that, it has the ability to support such a concept thanks to its enum known as an Option. An Option is nothing but an Enumeration defined as:
Enums let us enumerate all the possible values for a type. Option is a generic type of an enum hence can hold any type of value. Some represents that we have a valid value of type T and None is very similar to Null, which means that we have an invalid value.
Let’s look at an example:
Now, while using Some, the compiler can figure out the type wrapped inside the Some and hence the type can be verified. But obviously, the same can not be said about None. Hence we always need to annotate a None. But if Null was so bad, how is None any good? Look at the example code :
The above is not a valid statement. Here we try to add an integer to a Some of the integer, which simply, is a type mismatch. Had it simply been an integer, the compiler would have considered it to be a valid value and ignored it. But since its an Option, there is a possibility that it is a None, and the compiler would make sure that we cover all the cases in order to program safely. Therefore, we’ll need to extract the value out of the Some and then use it. Any issues thus can be uncovered while extracting the same.
Thus Option here :
- Explicitly makes us handle the case where the value might be a None.
- Helps us ensure that any non Option value is a valid value.
- Makes us confident of our code.
There are a lot of methods which we may use to extract the value out of the Option. For the full list, I would like you to refer the doc for the same since they are crucial in the journey of Rust. I would demonstrate a very commonly used method called unwrap().
unwrap() takes out the value out of the Some. However, since the result may not always be valid, this usage may result in a panic and is discouraged. We should rather work with pattern matching to achieve our aim.
This was a brief about Option in Rust. Please give your feedback on the same in the comments.