Add is-nan expression

[anandthakker]

We currently don't have very robust NaN handling in expression evaluation. For instance, ["typeof", ["^", -1, 0.5]] yields "number", even though the ^ expression produces a NaN.

[jfirebaugh]

For instance, ["typeof", ["^", -1, 0.5]] yields "number", even though the ^ expression produces a NaN.

I know people make fun of Javascript for typeof NaN === "number", but it's the correct semantics. NaN is an instance of the number type -- just a special one. Treating it differently would be more awkward.

[anandthakker]

Keeping NaN has its own awkwardness... e.g., when to-number fails, is it an error, or NaN? If to-number is used with fallbacks, does it stop at NaN or proceed to a fallback - i.e., what does ["to-number", "not a number", 10] return?

If we are going to allow NaN, though, we should add an is-nan expression.

[jfirebaugh]

when to-number fails, is it an error, or NaN

An error, like other conversion expressions.

["to-number", "not a number", 10] => 10
["to-number", ["^", -1, 0.5], 10] => NaN

we should add an is-nan expression

👍

[anandthakker]

Along with adding is-nan, we should add tests to make sure that all number-accepting expressions do something reasonable when they get a NaN (e.g., curve needs to behave reasonably when its input is NaN).

[jfirebaugh]

Related: #4172.

[ryanhamley]

I'm closing this as not necessary anymore since we added NaN handling in expression validation with #8615