Support NaN

[sliekens]

Please add NaN properties for every unit.

For example

• Energy.NaN
• Speed.NaN

Also add IsNaN(unit)

• Energy.IsNaN(Energy.NaN): true
• Energy.IsNaN(Energy.MaxValue): false

Thanks!

[angularsen]

We could, but I question the value of adding this.

double.IsNaN(Length.FromMeters(double.NaN).Centimeters) returns true, as expected.
Is this a matter of syntactic convenience?

I also notice that TimeSpan.FromSeconds(double.NaN) throws ArgumentException

TimeSpan does not accept floating point Not-a-Number values

Not sure what is the best practice here. Personally I might prefer throwing exception, not a fan of NaN bugs that are unnecessarily harder to debug. I very very rarely use NaN for anything useful.

[sliekens]

Is this a matter of syntactic convenience?

Yes. :)

I also notice that TimeSpan.FromSeconds(double.NaN) throws ArgumentException

I guess because TimeSpan stores its state as Int64 (number of ticks), and there is no Int64.NaN.

[angularsen]

@eriove @bretthysuik @maherkassim @tongbong

You are one of the top contributors, any input on NaN values?
a) Allow NaN values, can check double.IsNaN(myLength.Meters) (current behavior)
b) Allow NaN values, add IsNaN getter as syntactic convenience (suggested by @StevenLiekens)
c) Throw exception on trying to construct with NaN value, similar to how TimeSpan works (suggested by me, breaking change)

[bretthysuik]

My vote would be c) and to not re-implement .NET BCL NaN detection functionality in this library. double.IsNaN(myLength.Meters) is simple and clean enough to me without having to expand the API of this library.

[eriove]

Sorry for the late reply. Read the e-mail in my phone and forgot to reply.

c) is my favorite, since it catches errors early and NaN is usually an error when it comes to physical measures. Since it breaks backwards compatibility my second choice would be b. But I can't say I really care that much when choosing between a and b.

[angularsen]

It seems you both share my opinion on generally not facilitating the use of NaN. I'm adding a future reminder in #180 to consider option c) if we are going to bump the version later.

Seeing that you are both in favor of c), I think doing b) would just cause yet more future breaking changes, so that leaves a). Do nothing. The simplest solution to most problems :-)

Thanks for the input guys.