[Pre-RFC?] NonNaN type

Aaaaah, my error - I’ve changed my opinion on implementing arithmetic for NonNaN at some point during this discussion, and it has been hard to keep up with the different opinions here (and I think I may have confused a few avatars together).

Then I absolutely agree with you. NonNaN can maintain its invariant by not having mutating operations. And yes, NonNaN is only useful in particular contexts, especially implementing Ord. Otherwise you should extract a float.

1 Like

Thanks. I may have also gotten confused about some things… I didn’t mean to take over the discussion so much, but I’ve spent a lot of time over the last year experimenting with various float wrappers and fixed point types – precisely because I wanted to understand why they don’t exist or create them if they can. Largely the lesson I’ve learned is the float is actually really fantastic at solving the problems it is meant to solve.

Back on topic, there might be an interesting question of whether to implement Ord for Option<NonNaN> or just NonNaN, because it might allow you to choose whether to panic early or late. If you build a data structure which holds NonNans internally you can ensure early panics, but if it holds Option<NonNan>, you can defer the unwrap till the sort (or other op) and panic then. I don’t think there’s a good reason to be generic over these two modes, but if so, that’s a thing to think about.

2 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.