The Maybe-Value

Imagine two parcels on your doorstep. One is a plain sealed box with no label — you have no idea if there's a gift inside or just packing air, and you only find out when you tear it open. The other has a clear window: you can see at a glance whether it's holding something or sitting empty.

Most code today uses the first kind of box for "no value" — and it has a name. The maybe-value is the second kind: a box that's honest about whether it's full or empty, before you ever reach inside.

For decades, the standard way to say "there's nothing here" was null. A function that might not find an answer hands you back null, and everything looks fine — until some later line tries to actually use it. Then your program blows up with a crash, often far away from where the empty value first appeared.

The deep problem is that null is invisible. Nothing in the type tells you a value might be missing, so it's terribly easy to forget the empty case and discover it the hard way, in production, at 2am.

Here's how that plays out in F#. An order page prints a shipping label using three tiny functions, each calling the next. The user comes from a JSON row in the database, and Ada never saved an address. Step through it, and predict where the program crashes before you look.

The maybe-value fixes this by making absence visible. Instead of a sealed box that might secretly be empty, you get a clearly labelled box with exactly two states. Either it's Some x — it's holding a value, and there it is — or it's None — it's plainly empty, and everyone can see that.

The magic is that this lives in the type. The moment a value might be missing, the type says so out loud, and the compiler insists you deal with both cases instead of forgetting one.

Step through the same two users again, this time with Address declared as an Address option. The old cityOf hasn't changed yet: predict what happens when you build it.

That's the whole trade. The compiler won't let you treat a box as if it were the thing inside, so you can't forget the empty case — and in return, this value can never surprise you with a crash again.

The same honesty works for any lookup. Here's one that may or may not find a number:

// The `: int option` part is the honest label on the box
let tryFind (key: string) (table: Map<string, int>) : int option =
    Map.tryFind key table

tryFind "answer" myTable   // Some 42  — found it, here it is
tryFind "missing" myTable  // None     — clearly empty

That int option in the signature is the point: anyone reading it knows, before running a thing, that an answer might not come back. The absence is part of the contract, not a nasty surprise.

Here's the lovely part: you can often transform what's inside the box without unpacking it first. Option.map says "do this to the value if there is one; otherwise just leave the empty box empty." You never have to write a nervous "but what if it's missing?" check yourself.

let doubled = Option.map (fun x -> x * 2)

doubled (Some 21)   // Some 42  — the value inside got doubled
doubled None        // None     — nothing to do, stays empty

Notice the empty case took care of itself. The doubling only happened where there was something to double, and the None sailed straight through.

Eventually you'll want a plain value back, not a box. When the box is empty, Option.defaultValue lets you supply a fallback to use instead:

let count = tryFind "visits" stats        // int option
let display = Option.defaultValue 0 count  // if empty, use 0

In plain words: "if there's a value, use it; if it's empty, use this default instead." Now display is always an honest int, with the missing case handled in the open rather than ignored.

Real code rarely stops at one lookup. To show a balance you find the user, then their account, then the balance — and any of the three might come up empty. With nulls, that means a null check before every step. With maybe-values, you chain the steps and let the boxes do the checking:

let balanceFor userId =
    findUser userId                  // User option
    |> Option.bind findAccount       // runs only if there's a user
    |> Option.bind findBalance       // runs only if there's an account

Each line hands the box to the next lookup only if the box is full. The moment one comes up empty, every step after it is skipped and None comes out the end. In plain words: if any step comes up empty, skip the rest.

Predict where the chain stops for user 7, who has no account yet. Then switch users to see the happy path and an early stop.

What makes this so calming is that the empty case stops being a landmine. With null, missing meant maybe a crash later. With a maybe-value, missing is just one of two clearly labelled states, and every step either handles it or politely steps around it.

There's one thing None can't tell you: which step came up empty, or why. When the caller needs the reason — "no such user" versus "account frozen" — swap the empty box for one that carries an error message. That's the success-or-failure railway, where a failure rides a parallel track to the end with its explanation attached.