Well, I would kindof consider that to be an implementation of that approach, if you think of NaN as an error return. The important part is that you don&#x27;t return a value that is arithmetically incorrect for the expected semantics, but not recognizable as such by itself.<p>I think the approach of Rust is stupid because it makes the fast but insecure option the default for all the code that&#x27;s written without thinking about it too much that isn&#x27;t in any way performance critical. Most arithmetic operators in code are not performance critical, only a few that are executed often, are, so it doesn&#x27;t make much sense to make the behaviour that you need in that case the default, when that also is a security risk. And overflow checking only in debug builds is kindof useless from a security perspective.<p>Having different types instead of different operators also is weird. You don&#x27;t have &quot;additive integers&quot; and &quot;multiplicative integers&quot; either, where the former&#x27;s &quot;+&quot; operator does addition, while the latter&#x27;s does multiplication (which is a form of (repeated) addition, after all!). If you have the same set of numbers to operate on, the obviously sensible thing to do is to have different operators for different ways to map pairs of those numbers to single numbers from the same set.