Null-checking considerations in F# – it's harder than you think

It sounds like this boils down to a codegen problem&#x2F;bug with == &#x2F; &lt;&gt;, mm? I recall a similar problem doing comparisons on some value types, perhaps it was DateTime (IIRC, this was before VS2010). The fix was to add another case to the operator to make it take the fast path (do a direct call to the compare method vs some crazy generic path). Rather than make the code more verbose to hack around compiler limitations, fix the compiler? Though:<p><pre><code> if x == null then ... else ... </code></pre> is about the same as:<p><pre><code> match x with null -&gt; ... | _ -&gt; ... </code></pre> That said, null checking was never a perf area nor anything I&#x27;ve really had to deal much with in years of working with F#.

Is there some .NET platform &#x2F; interop issue that requires F# to have null references? SML and OCaml have Option types and Haskell has the Maybe Monad. It seems weird that F#, being an ML-family language, requires checking for references to null.

This is really good stuff, but most importantly remember that every time you go out to .NET and could get a null, sort it all out as close to the call as possible. Don&#x27;t be cute and wrap it in an option, or try some 3-levels-out try-catch block from hell. Acknowledge what could happen and deal with it.<p>I&#x27;ve found that every little bit my code gets away from that call without handling the null, things get more and more complicated.