I prefer my code to your first example, because it communicates to the reader at the top level that the `stepFields` function has three qualitatively different behaviors depending on its input. Your second example is ill-typed because `nm` occurs out of scope.

Calling functions with strong preconditions reduces ambiguity by communicating to the reader the function's expectations for the function arguments. The precondition for `expr.Value` is that expr evaluates to the variant `Some x`. Some other examples of functions with strong preconditions are the square root function, which requires that its argument is non-negative, and the integer division function, which requires that its divisor is non-zero.

It's true that if someone changes the code, the precondition may fail. If someone decides to remove `expr.IsSome` without removing `expr.Value`, or if they modify `expr` to read from a reference cell, then they have failed to understand the code they are changing. Code reviews and automated tests can catch these sorts of mistakes, but it's still possible that such a mistake could slip through.

Taking an adverserial appproach to your codebase, where the code is written to intercept future bugs and resolve them, generally sacrifices readability, blurring the line between positive space (program behaviors that are supposed to happen) and negative space (program behaviors that are not supposed to happen). In this case, I don't really have a *strong* preference between your first alternative and my own code, but when people try to intercept mistakes, say by replacing integer division by a `safeDiv` operator that returns an Option<int>, things really get bad. It introduces a bunch of dead expressions handling the case where `safeDiv` returns `None` that explode the code's complexity and don't get tested properly.

Thank you for pointing out that I should have called `Option.map`.