Invalid calculations produce NaN?

[saxbophone]

This could be a useful feature for distinguishing between integer zero and "invalid" values, such as in the return values for numeric_limits members that aren't defined, such as max().

[saxbophone]

Nat foo; // NaN
Nat bar = 0; // 0
Nat baz = {}; // 0 ?

[saxbophone]

I wonder if an implementation with an anonymous struct like this might make sense:

struct {} NaN;

void something(decltype(NaN)) {}

int main() {
    something(NaN);
}

Or perhaps we should just name it NanType.

Not sure yet whether we want to simply allow it to propagate unknowns or for it to also be the result of invalid operations such as square root of negatives, divide by zero and what-not. We currently throw an exception for the latter case and this may or may not be more desirable.

We'd also need to provide an override of the spaceship operator to also work with NaN and additionally, provide a converting constructor for converting NaN to a Nat object (so we could return NaN from methods in some cases and know it will automatically convert to an empty Nat.

Note: I think we won't need to overload the spaceship operator if we provide a converting constructor from NAN to Nat, as long as it's an implicit constructor. Need to test this with unit tests to confirm...

Hmmm, maybe we really should name it something like Empty or Missing instead.

[saxbophone]

Alas, after getting feedback on this design (https://codereview.stackexchange.com/questions/283562/api-design-for-implementing-nan-unknown-values-for-custom-numeric-type), I will not be having empty objects produce NaN —but if we want to replace exceptions with NaN for impossible values, we can follow roughly the approach outlined in that code review, whilst following the recommendations in the feedback.