News for hackers. Stuff that matters.
Re:Myths about Integer Overflow in Rust by weinzierl on Friday April 29, 2016 @07:00PM (#11599286)
It's not the same as an error return because the NaN propagates through all subsequent calculations.

In numerical code very often there are no checks for NaN at all. I'd even go so far to say that a lot of FORTRAN code in use today was written before NaN was introduced. I/O functions like printf or WRITE treat NaN properly so if something went wrong you end up with the string "NaN" in your output.

In rust the checked_... methods that return an Option come close to the NaN behaviour.

Re:Myths about Integer Overflow in Rust by zAy0LfpBZLC8mAC on Friday April 29, 2016 @07:52PM (#11599508)
NaN is a value that is returned to indicate that an operation could not be performed in the way that is normally expected. How is that not pretty much the definition of an error return?

Propagating an error return through subsequent computations is just monadic error handling ... which is, well, error handling?

Also, of course, there are NaN checks everywhere, as is evidenced by the error propagation. You can't propagate the sentinel value if you don't check for it. It just so happens that this check usually is implemented in hardware as part of every instruction for IEEE 754 numbers, so it's extremely fast in the error-free case and doesn't cause any code bloat, at the cost of some cycles being spent on otherwise useless error propagation in case an error occurs.

Now, what you are saying isn't exactly wrong--but I think it's much less confusing to think of it in this way.