4 ms·

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't return

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't return a value that is arithmetically incorrect for the expected semantics, but not recognizable as such by itself. I think the approach of Rust is stupid because it makes the fast but insecure option the default for all the code that's written without thinking about it too much that isn'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'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. Having different types instead of different operators also is weird. You don't have "additive integers" and "multiplicative integers" either, where the former's "+" operator does addition, while the latter'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.

weinzierl 11y ago
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.
- zAy0LfpBZLC8mAC 11y ago
  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.
reycharles 11y ago
n+1 is a number.

weinzierl 11y ago

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.

zAy0LfpBZLC8mAC 11y ago
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.

reycharles 11y ago

n+1 is a number.