Clarification on handling +∞, -∞ and Nan for numeric ranges and BigInt

[MundiaNderi]

Hello,

I'm currently implementing the Iterator.range proposal in SpiderMonkey at Mozilla. While working on the NUMBER-RANGE implementation and extending it to support BIGINT, I encountered ambiguity in the specification when handling +∞, -∞, and NaN. The following points require clarification.

As the proposal stands, there's validation issues when handling +∞, -∞ and Nan specifically in steps:

Step 5. If start is +∞𝔽 or -∞𝔽, throw a RangeError exception. - I need to specify that typeof start is a number, otherwise throws an error that start should be finite.

Step 13. If step is NaN, throw a RangeError exception. - I need to check that step isNumberRange otherwise it throws: The 'step' argument must be a finite number.

Step 16. If step is +∞𝔽 or -∞𝔽, throw a RangeError exception. - Also needed to specify that type of step isNumberRange

[ljharb]

(Please ensure the implementation is flagged until it's in stage 2.7 or 3; stage 2 is too early to ship an unflagged implementation)

Step 3.a and 4.a already ensure that start is either a Number or a BigInt, and step 5 will thus only pass if it's a Number that's one of the infinities - I don't think anything needs to be done here.

Step 7.a, 9.a, and 10.a ensure it's a Number or a BigInt - so i think it's just that step 8.a needs a step inserted after it that throws if it's not a Number or a BigInt. That should cover your issue with both step 13 and step 16, I think?

[dminor]

Thanks :)

It sounds like from a specification point of view, it's ok to compare a BigInt value against a Number value like NaN or +∞𝔽? If that's the case, then I think Serah's original question is a SpiderMonkey implementation detail and not a specification issue.

[ljharb]

I don't see why it wouldn't be OK - the comparison would just always be false.

[bakkot]

Implementations are usually written in typed languages where that sort of thing isn't allowed. But yes, from the spec point of view it's perfectly fine, and an implementation in a typed language would just need to write the check in a slightly different way.

[Jack-Works]

From my understanding of the specification, we're allowed to compare the equality of different types of numbers, so I think the spec is correct, please let me know if you have more questions!

[anba]

There are definitely some issues around numeric types in https://tc39.es/proposal-iterator.range/#sec-create-numeric-range-iterator.

• zero and one are both initialised to BigInts.
• currentCount is initialised with zero and later updated using one, so currentCount is also a BigInt.
• But that makes (step * currentCount) an invalid expression when step is a Number.

Also expressions like step > zero are not defined when step is a Number, because zero is a BigInt.

See https://tc39.es/ecma262/#sec-mathematical-operations:

Numeric operators such as +, ×, =, and ≥ refer to those operations as determined by the type of the operands. [...] Numeric operators applied to mixed-type operands (such as a Number and a mathematical value) are not defined and should be considered an editorial error in this specification.

Identity tests using is are special and can be applied to mixed-type operands, cf. https://tc39.es/ecma262/#sec-identity.

[Jack-Works]

Thanks for pointing out this! I'll fix this later

[Jack-Works]

hi! I have created #76 to fix this, stopping comparing Infinity with BigInt values, and I believe it's impossible to involve NaN values during the comparison. Please take a look thanks!