Well, I’m not saying that I want to take tools away. I’m explicitly saying that a ieee_754_f64 type could exist. I just want it to be named annoyingly, so anyone who doesn’t know why they should use it, will avoid it.
If you chain a whole bunch of calculations where you don’t care for NaN, that’s also perfectly unproblematic. I just think, it would be helpful to:
Nudge people towards doing a NaN check after such a chain of calculations, because it can be a real pain, if you don’t do it.
Document in the type system that this check has already taken place. If you know that a float can’t be NaN, then you have guarantees that, for example, addition will never produce a NaN. It allows you to remove some of the defensive checks, you might have felt the need to perform on parameters.
Special cases are allowed to exist and shouldn’t be made noticeably more annoying. I just want it to not be the default, because it’s more dangerous and in the average applications, lots of floats are just passed through, so it would make sense to block NaNs right away.
Well, I’m not saying that I want to take tools away. I’m explicitly saying that a
ieee_754_f64type could exist. I just want it to be named annoyingly, so anyone who doesn’t know why they should use it, will avoid it.If you chain a whole bunch of calculations where you don’t care for
NaN, that’s also perfectly unproblematic. I just think, it would be helpful to:NaNcheck after such a chain of calculations, because it can be a real pain, if you don’t do it.NaN, then you have guarantees that, for example, addition will never produce aNaN. It allows you to remove some of the defensive checks, you might have felt the need to perform on parameters.Special cases are allowed to exist and shouldn’t be made noticeably more annoying. I just want it to not be the default, because it’s more dangerous and in the average applications, lots of floats are just passed through, so it would make sense to block
NaNs right away.