My point is I don’t want to lose the let it crash semantics by replacing it with lots of unnecessary checking code to keep the compiler happy throughout the code base and community libraries adopting bad defensive coding idioms and still have essentially the same runtime behaviour.
I like the contract semantics of Elixir, no match results in a crash. I don’t want functions accepting bad input that it has to check to avoid a compiler warning. The responsibility must be pushed to the caller, not the callee.
I have already played devils advocate and shown how good intentions can lead to bad outcomes.
The one thing we actually want out of the compiler checks is to identify root causes of problems. If the problem appears to be an unhandled case, developers will add the catchall clause. So now we silence the compiler and the developer feels like they did some good. However, depending on where this case expression lives, what they just did is potentially fail to address the root cause at a boundary layer. If it’s in a boundary or santisation layer then great they addressed bad external input, however if it’s further down the call graph where library authors code defensively to handle bad input then the developer has not addressed the root cause, and has allowed unsanitised input to flow throughout the code.
The worst outcome is that defensive coding everywhere hides the root cause and shifts the effort into fixing the wrong code. We ultimately want the boundary layer to deal with santisation and the sad paths and the core of our applications and business logic to deal with the happy path.
Hence anything the compiler can do to pinpoint the origin of the unsanitised / unprovable input further up the call graph helps developers put the defense’s in the right place.
