I wouldn't call it a side-effect, as in this case it is very much intended; we declaratively state that this option needs to be an Integer and we raise an appropriate exception if the client supplies bad input of any sort. My assertion here is that `nil` and `false` (and `"foo"` and `1.1` for that matter) in this case are bad input and should be rejected as such, not massaged into something we hope the client means.

I've been bitten too many times by the unintended side-effects of pushing out a code change in a library only to find out a client was using it in an undocumented way and I have unknowingly broken userspace, so I find it far more useful to require the client adhere to the API than to keep track of every instance of how-to-handle-bad-data in perpetuity for the lifetime of the project.