I usually pattern match myself, consider these two cases:
myVar = someFunction("blah")
# Case 1
first = List.first(myVar)
# Case 2
[first|_] = myVar
# Case 3
case myVar do
[first|_] -> useFirst(first)
[] -> doOtherwise()
end
Case 1 is using List.first, it works.
Case 2 is pattern matching, same as Case 1 but I like it as it makes it explicit what it is doing.
Case 3 is a case statement, longer sure, but the usage of the match is handled and if the list is empty that is also handled.
However, what if myVar was nil? Maybe even through no fault of someFunction/1 but rather some other call or so. Cases 1 and 2 and 3 all crash.
A statically typed system on the other hand has to know what is returned, like given this equivalent OCaml code:
let myVar = someFunction "blah" in
(* Case 1 *)
let first = List.hd myVar in
(* Case 2 *)
let first::_ = myVar in
(* Case 3 *)
match myVar with
| first::_ -> useFirst first
| [] -> doOtherwise ()
Given someFunction "blah" can only return a list (otherwise it throws an exception if an exceptional condition):
- Case 1 → Compiles and works as expected, returns first as
firstelse throws an exception. - Case 2 → Compiles and works as expected, returns first as
firstelse throws an exception. - Case 3 → Compiles and works as expected, you handle all paths.
However, given someFunction "blah" can return a list or () (Ocaml’s version of nil) as a Result.t or just an option, say because of an internal refactor later on in the project and the above original code was missed in the update, then:
- Case 1 → Will not compile, List.first only accepts a variable that can only be a nil
- Case 2 → Will not compile, the match construct cannot match anything of myVar, have to decompose the option.
- Case 3 → Will not compile, the match construct cannot match anything of myVar, have to decompose the option.
You either have to withDefault the option/result to a default value to get back to the original handling, or you have to handle the option properly. In either case in a dynamic language this is missed and will crash sometime later (hopefully in tests, most likely in prod, especially if the tests do not test a nil case because there was no nil case originally). Dialyzer ‘might’ catch this if all paths can be confirmed, but that cannot be guaranteed. 
