Throw on unsafe integers? [feedback on Apr 2024]

[Jack-Works]

based on feedback at the Apr 2024 meeting

@erights thinks we should throw on unsafe integers, and @waldemarhorwat thinks we should allow it. This is one of the blocking concerns of advancing to stage 2.7.

In addition, by "throw on unsafe integers", there are 3 possible approaches I wonder which one @erights expects:

• Throw on unsafe start/end/step (parameter check)
• Throw when the number yielded grows from safe to unsafe
• Both of above

[tabatkins]

Given the way we do incrementing (start + step*N), unsafe integers are still "safe" in that we're guaranteed to eventually hit the end condition. Exactly when we hit that condition might not be clear when working with unsafe integers, but that's an inherent property of doing math with unsafe integers using Number; the exact same lack of clarity would occur if you were figuring it out yourself, unless you knew exactly what you were doing and compensated for the unsafeness manually.

For example, Iterator.range(Number.MAX_SAFE_INTEGER, Number.MAX_SAFE_INTEGER + 100, 1) will yield 100 values, as expected, but Iterator.range(Number.MAX_SAFE_INTEGER, Number.MAX_SAFE_INTEGER + 101, 1) will also yield 100 values. And in both cases, there will only be 51 unique values (the max safe integer, and the 50 even integers following it). But that's exactly what you'd get with for(let start = Number.MAX_SAFE_INTEGER, end=Number.MAX_SAFE_INTEGER+100, step=1, i=0; start+i*step < end; i++) { let val = start+i*step; process(val); } anyway.

I don't think we're usefully saving anyone from themselves by throwing in this case. If the author needs to worry about safe integers, they need to do it at the boundaries of their code anyway, and only carefully modify those proven-safe values; random operations inside the boundary checking for safety as well won't increase their overall safety. The entire rest of math performed on unsafe integers silently works just fine; there's perhaps an argument for an interpreter option that throws on all unsafe integer math, but I don't think it's very useful for an arbitrary subset of functions to do so.

So, I recommend rejecting @erights objection.