My thinking is that a call to the safe division method would check after the division, whether the result is a NaN. And if it is, then it returns an Error-value, which you can handle.
Obviously, you could do the same with a NaN by just throwing an if-else after any division statement, but I would like to enforce it in the type system that this check is done.
It doesn’t have to “error” if the result case is offered and handled.
Float processing is at the hardware level. It needs a way to signal when an unrepresented value would be returned.
My thinking is that a call to the safe division method would check after the division, whether the result is a
NaN. And if it is, then it returns an Error-value, which you can handle.Obviously, you could do the same with a
NaNby just throwing an if-else after any division statement, but I would like to enforce it in the type system that this check is done.I feel like that’s adding overhead to every operation to catch the few operations that could result in a nan.
But I guess you could provide alternative safe versions of float operations to account for this. Which may be what you meant thinking about it lol
I would want the safe version to be the default, but yeah, both should exist. 🙃