Unreachable NaN branch in the constructor

[jessealama]

The Amount constructor parses String arguments with |StringNumericLiteral| and throws a RangeError if parsing fails. The algorithm then contains a branch that checks whether the parsed mathematical value is ~not-a-number~ and, if so, stores the Number value NaN. The intention is clear enough, but that branch is actually unreachable: |StringNumericLiteral| does not match "NaN". Thus, new Amount("NaN") throws a RangeError before checking for ~not-a-number~.

Comparing with how Number arguments are handled in the constructor, notice the asymmetry:

new Amount(NaN);      // Amount with value NaN
new Amount("NaN");    // RangeError

[gibson042]

I'm not sure I want Amount to have different behavior for numeric consumption of "NaN" vs. e.g. "abc", which would be unique in the language.

[eemeli]

What's the use case for new Amount('Infinity') not throwing an error?

For me, the overall logic would be most consistent if Amount supported only finite numeric string values, with normalization.

[jessealama]

A couple of plenaries ago, we received feedback that if we support Number arguments in the constructor, we should support all Numbers, including the infinities, -0, and NaN. And for consistency, one can reasonable conclude: if we support all of Number, then we should String renderings of all Numbers.

I'm also in favor of using Strings representing finite values in Amount. But if we do that, then we run the risk of being somewhat inconsistent.

[jessealama]

It sounds like we're leaning toward rejecting String arguments that don't look like a decimal digit string. And going along with the discussion in #133 , those strings should not have any padding (neither on the left- nor right-hand sides of the digits).

The data model would remain unchanged. We'd still accept NaN, etc. Just not "NaN", etc.