Editorial: fix two [[FooIteratorNextIndex]] descriptions #1784
Conversation
... that refer to the index of an index rather than the index of an element. [Cherry-picked from PR tc39#1623.]
| @@ -30296,7 +30296,7 @@ <h1>Properties of String Iterator Instances</h1> | |||
| [[StringIteratorNextIndex]] | |||
| </td> | |||
| <td> | |||
| The integer index of the next string index to be examined by this iteration. | |||
| The integer index of the next string element (code unit) to be examined by this iteration. | |||
There was a problem hiding this comment.
I am most certainly wrong, but doesn't StringIterator go over code points?
There was a problem hiding this comment.
It's true that the next() function returns a code-point-worth of string, but [[StringIteratorNextIndex]] remembers its position as an ordinary (code-unit-wise) index into the string.
(If it remembered its position as a code-point offset, each call to next() would have to re-scan the string to know what to look at next.)
There was a problem hiding this comment.
Thank you for explanation. I believe #1579 can possibly supersede this change?
There was a problem hiding this comment.
Indeed it can! (Sorry, I wasn't paying attention.)
In the likely event that it gets merged, I'll close this PR.
This one's my fault: during review of PR tc39#1464, I suggested a change to (what is now) the "Parse" line, without noticing that it stranded the "Otherwise" line.
|
Subsumed by #1579, I believe, which was just merged. |
... that refer to the index of an index rather than the index of an element.
[Cherry-picked from PR #1623.]