F# Friday – The Option Type, Part 1

It’s like that time you played basketball in the living room. You knew you should never have done it. But it was just so tempting! And how did that work out for you? Broken lamp? Hole in the wall? And, if you grew up in a house like mine, a tanned hide to follow. You could have avoided it all: the property damage, the wounded pride, the tender backside.

That’s what playing with null is like. You know you shouldn’t, but it’s just so easy! Then you get burned in the end.

The Problem with Null

The problem with null is that it can crop up anywhere an object can. Consider a function that returns a string. This is always OK, right?

let foo : unit -> string = // ...
let len = foo().Length // No worries?

It certainly is in this case:

let foo : unit -> string = fun () -> "foo"
let len = foo().Length
// val len : int = 3

But what about this?

let foo : unit -> string = fun () -> null
let len = foo().Length
// System.NullReferenceException:
//   Object reference not set to an instance 
//   of an object.

Yeah, not so much. And the problem is that the compiler cannot help us: null is a perfectly legal return value.

We need better semantics! A return type of string ought to guarantee me that I get a string. An empty string would be fine; it just needs to be a string!

Even the guy who invented the concept of null has regretted it:

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). 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.

Sir Charles Antony Richard “Tony” Hoare
Turing Award Winner, Inventor of the Quicksort
Null References: The Billion Dollar Mistake (2009)

Fine! All this lamenting that null is a bad idea is great, but don’t you need a way to represent the idea that sometimes a function may not return a result, or at least, not what you would consider a valid result? That’s what Java does: If you call Map.get(key), and that map does not contain an entry for key, you get null. As we saw couple of weeks ago, F#’s List.find (and the other collections’ find functions, too) is not any more elegant: It throws an exception!

There’s got to be a better way!

Option to the Rescue

When you need to represent the idea that a function may not return a result, use F#’s Option. You can think of an Option as a bucket (pronounced BUCK-et, not boo-KAY):

The Option type illustrated as a bucket. The bucket may be empty or full. If the Option contains a value (represented by the full bucket), we call it "Some." If the Option does not contain a value (represented by the empty bucket), we call it "None."
The Option Type: Is the Bucket Empty or Full?

When a function returns an Option<'T>, it may contain a value of type T; it may not. You don’t know until you look into it. It’s Schrödinger’s cat! If the Option is empty, we call it None. If it is full, we call it Some.

The advantage of using Option is that now the compiler can help you out. You cannot assign an Option<'T> to a variable of type T. Take this example using List.tryFind:

let opt = [1..4] |> List.tryFind (fun n -> n > 5)
let n : int = opt
//   let n : int = opt;;
//   --------------^^^
// 
// This expression was expected to have type
//     int    
// but here has type
//     int option

So then, you cannot forget and accidentally assign a null, only to have it bite you later. The compiler reminds you that you need to test the result before trying to use it:

let ns = [1..4]

let none = ns |> List.tryFind (fun n -> n > 5)
if none.IsSome then
    printfn "Found one greater than 5: %d" none.Value
else
    printfn "None found greater than 5"
// None found greater than 5

let some = ns |> List.tryFind (fun n -> n < 5)
if some.IsSome then
    printfn "Found one less than 5: %d" some.Value
else
    printfn "None found less than 5"
// Found one less than 5: 1

Of course, you can override the safeguard, but at least then, you cannot claim ignorance:

let ns = [1..4]
let none = ns |> List.tryFind (fun n -> n > 5)
printfn "Found one greater than 5: %d" none.Value
// System.NullReferenceException:
//   Object reference not set to an instance 
//   of an object.

Next week, we will look at Option some more to see how we can use it in a more functional fashion.

2 thoughts on “F# Friday – The Option Type, Part 1”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.