Should ToIntlMathematicalValue accept non-decimal number strings? about proposal-intl-numberformat-v3

[sffc]

@romulocintra I'm assigning this issue to you to fix in corrdination with #72. I think once we update the proposal to use the |StringNumericLiteral| grammar as @bakkot proposed, this issue will be fixed.

We should also add Test262 for this behavior, of course.

[sffc]

Hmm, interesting question.

I don't necessarily see anything wrong with accepting "0x10". It's an interesting side-effect of the way I implemented ToIntlMathematicalValue.

I'd like if an editor (@ryzokuken?) could take a closer look at ToIntlMathematicalValue and provide feedback here.

https://tc39.es/proposal-intl-numberformat-v3/out/numberformat/diff.html#sec-tointlmathematicalvalue

[sffc]

CC @bakkot, @ljharb, and @waldemarhorwat to take a closer look at ToIntlMathematicalValue.

[anba]

Hmm, "0x10" was probably a bad example, because that's already supported now. Larger number strings like "0x20000000000001" are more interesting, because there's only a difference when the number is larger than Number.MAX_SAFE_INTEGER.

[bakkot]

Given https://github.com/tc39/proposal-intl-numberformat-v3#interpret-strings-as-decimals-ecma-402-334, I take it the intention is to allow arbitrary numeric strings to be interpreted precisely, not just those strings which are precisely representable as Numbers?

If so, the current spec text does not do that. In particular, ToIntlMathematicalValue step 6 is Let mv be the MV, a mathematical value, of ? ToNumber(str), as described in 7.1.4.1.1. This passes through ToNumber, which means that it loses precision.

I'm happy to suggest a change to the spec text to make it handle precise values in binary, octal, decimal, and hex, (i.e. the current formats), if that's the intention. (I think there might be implementability concerns with that, but that's not my area.)

[sffc]

If so, the current spec text does not do that. In particular, ToIntlMathematicalValue step 6 is Let mv be the MV, a mathematical value, of ? ToNumber(str), as described in 7.1.4.1.1. This passes through ToNumber, which means that it loses precision.

The intent of that section was to extract the private variable called MV out of ToNumber before it gets flattened into a Number. In other words, leverage the string grammar, but keep the full precision mathematical value.

About non-decimal strings (binary, octal, hex): Precise values in decimal is the primary use case, and is what ICU handles. The use case is not as strong for binary, octal, and hex. If they are easy to implement in the browser engine, I think we should go for it, but if it presents challenges, then it's fine to call it out of scope.

@FrankYFTang thoughts?

[anba]

If they are easy to implement in the browser engine, I think we should go for it, but if it presents challenges, then it's fine to call it out of scope.

It's (currently) not difficult to implement, because right now all non-decimal number strings are guaranteed to be integers, so implementations can simply parse them as BigInts. Should we ever support the hexadecimal floating point notation (e.g. 0x1.24p0), more work will be necessary.

[sffc]

Discussion 2021-11-04: https://github.com/tc39/ecma402/blob/master/meetings/notes-2021-11-04.md#should-tointlmathematicalvalue-accept-non-decimal-number-strings

Consensus: "I think we should accept all grammars currently accepted, and the only behavior difference is that we should resolve the numerical values to be mathematical values, instead of downcasting them to Number."

[rwaldron]

@sffc the issue that's linked from that discussion has a typo in it, "proposal" => "proposals"; but it also points to 4 year old issue about method shorthand that was closed for "wrong venue". Can we get a corrected link? Thanks!!

[sffc]

The link should point back to this issue. Fixed.