The solution to "Error handling"...

[Jonathan M Davis]

On Saturday, July 4, 2026 3:20:04 PM Mountain Daylight Time Walter Bright via Digitalmars-d wrote:
> On 7/4/2026 1:01 PM, Jonathan M Davis wrote:
> > And from what I've seen, much as most of us absolutely hate the
> > whole mess with NaNs, the guys who actually do a lot of math with their
> > programs love it.
>
> Here's a nice explanation of why NaNs are needed:
>
> https://pzarycki.com/en/posts/js-nan/
>
> NaNs are your friend with computer floating point math. The whole mess would
> (and did) exist before NaN was invented and standardized.

I'm aware, but IMHO, the result is a disgusting mess. But honestly, I hate
floating point values in general. Integers don't behave entirely like proper
math, but they basically do outside of the fact that you have to worry about
overflow and the fact that they have truncating division. So, you can mostly
ignore the fact that they don't entirely behave like proper math, and
they're pretty reasonable to work with.

Floating points on the other hand get all kinds of screwy depending on the
math you use, with the order of operations affecting precision and the like.
Don did a good talk on them at dconf a number of years ago, explaining what
to watch out for and how to deal with them, but if anything, it just further
cemented my opinion that they should be avoided as much as possible.
Sometimes, you don't have a choice, but if I do have a choice, I don't use
them. If we had a fixed precision decimal type, then I'd likely use that
instead, though that likely comes with its own problems. Of course, what
would we'd ideally have would be types that behaved like actual math, but
computers obviously have limitations which make that impossible.
(particularly when you care about performance).

And the fact that floating point values make it so that you can't require
that operations such as the comparison operators behave reliably across all
types just makes the situation that much worse. There are clearly good
reasons for why those operations work the way that they do with floating
point types, and we're pretty much stuck with them being that way, but it
makes it so that you can't rely on those operations being consistent across
types, which is bad for generic code in particular.

So, I'm not proposing that D does anything different with floating point
types, and if I were to create my own language, I'd probably implement them
the same way that they are in D, because we really don't have a good
alternative. But I _really_ don't like them.

- Jonathan M Davis