Normative: use Numbers instead of reals as counters in Iterator builtins#3776
Normative: use Numbers instead of reals as counters in Iterator builtins#3776michaelficarra wants to merge 3 commits into
Conversation
michaelficarra
added
normative change
|
The rendered spec preview for this PR is available as a single page at https://tc39.es/ecma262/pr/3776 and as multiple pages at https://tc39.es/ecma262/pr/3776/multipage . |
|
In #2007 we discussed the issue of counters and IIRC agreed that we should specify them as mathematical values with the understanding that implementations would diverge in the same way they diverge from the requirements to have arbitrarily large strings and callstacks and similar. I think that's better than this. |
|
Even JSSE, the entirely AI-generated engine, gets this wrong: https://github.com/pmatos/jsse/blob/main/src/interpreter/builtins/iterators.rs. I guess it didn't read the spec... |
michaelficarra
force-pushed
the
mathematical-counters
branch
from
56466b4 to
a5e3a69
Compare
|
(When I tried to suggest this on the 'changes' page, GitHub acted weird:) |
|
Oh, thank you @jmdyck! |
michaelficarra
force-pushed
the
mathematical-counters
branch
from
60065a8 to
20e6fb7
Compare
| 1. Repeat, while _remaining_ > 0, | ||
| 1. If _remaining_ ≠ +∞, then | ||
| 1. Set _remaining_ to _remaining_ - 1. | ||
| 1. Let _remaining_ be 𝔽(_integerLimit_). |
There was a problem hiding this comment.
Given the check above that _numLimit_ is either Infinity or a safe integer, what is the observable difference between doing all of these steps in the floats space vs mathematical values space?
There was a problem hiding this comment.
I don't think there is one. Just makes it very obvious to implementers that it's okay to do all of this with floats.
There was a problem hiding this comment.
The changes look correct.
I have a slight preference for keep using mathematical values for the take/drop counters, but we already have other two precedents for using floats:
Floats also have the minor advantage of not needing special handling for infinity (but we could also just define what infinite - 1 means for extended mathematical values).
Aligns Iterator.prototype.take and Iterator.prototype.drop with the normative changes in tc39/ecma262#3776. Specifically, if numLimit is finite and strictly greater than 2^53 - 1 (kMaxSafeInteger), V8 now correctly closes the iterator and throws a RangeError. TAG=agy CONV=df8a3037-745d-4141-afa0-f7f025cb3248 Bug: 476989751 Change-Id: I27fa44e1ee6708edf8fa5fa62f5d7c5012ebdb7a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7859692 Reviewed-by: Nikolaos Papaspyrou <nikolaos@chromium.org> Commit-Queue: Olivier Flückiger <olivf@chromium.org> Auto-Submit: Olivier Flückiger <olivf@chromium.org> Cr-Commit-Position: refs/heads/main@{#107429}
5 participants
All known engines are currently non-compliant. If they use Numbers as counters today, they'll stop advancing at 253. So counters passed to user-provided callbacks will always be 253 once they reach that point and take/drop will behave as if Infinity was passed. With this change, internal counters are now Numbers, so the argument passed to user-provided callbacks is expected to repeat at 253 (matching implementations today). In addition, take/drop throw a RangeError on finite inputs ≥ 253.
See tc39/proposal-iterator-includes#12 for context.