-
Notifications
You must be signed in to change notification settings - Fork 0
Add draft spec text for TypedArray.concat #6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
The rendered spec for this PR is available at https://tc39.es/proposal-typedarray-concat/pr/6. |
bc7b5cd to
7672833
Compare
| 1. Let _C_ be the *this* value. | ||
| 1. If IsConstructor(_C_) is *false*, throw a *TypeError* exception. | ||
| 1. If _C_ does not have a [[TypedArrayName]] internal slot, throw a *TypeError* exception. | ||
| 1. Let _arrayList_ be ? IteratorToList(? GetIteratorFromMethod(_items_, ? GetMethod(_items_, %Symbol.iterator%))). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works but is not idiomatic - the convention is to consume iterables as iterables, meaning that you'd be doing the ValidateTypedArray calls on each item as you consume the iterable, rather than deferring those checks until after the whole iterable has been consumed.
That said, there's arguably a reason to do it this way, which is that the iteration protocol calls user code, which could detach or resize a TypedArray that you've already looked at, which would be bad. Doing it this way ensures there's no user code running between the point at which you start computing the total length and the point at which you do the copies. If that's the intention, that's reasonable, but this should probably should be called out with a NOTE.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
doing it this way, however, means that it can still throw conceptually mid-iteration, and the iterator will have been exhausted.
iow, i think that the extra burden of checking for resizing or detachment is necessary if it's going to take an iterable, so that an error on an item in the middle doesn't exhaust the iterator.
| 1. Let _itemLength_ be TypedArrayLength(_taRecord_). | ||
| 1. Set _totalLength_ to _totalLength_ + _itemLength_. | ||
| 1. If _length_ is present and _length_ is not *undefined*, then | ||
| 1. Let _newLength_ be ? ToIndex(_length_). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per our new-ish normative conventions, this should throw if _length_ is anything other than a nonnegative integral number (rather than doing a coercion, as ToIndex does).
(If you were doing a coercion it would best be done above, so that you avoid running user code after looking at the TypedArrays, but the point should be moot because we should not be doing coercion.)
No description provided.