Add draft spec text for TypedArray.concat #6
Conversation
|
The rendered spec for this PR is available at https://tc39.es/proposal-typedarray-concat/pr/6. |
jasnell
force-pushed
the
jasnell/spec-draft-text
branch
from
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.
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.
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.
There was a problem hiding this comment.
It's a tradeoff - I agree that in the error case that it is very slightly nicer to not exhaust the iterator, but if that comes at the cost of slowing down the happy case, as I think it might here, it's not necessarily worth it.
There was a problem hiding this comment.
Hmm.. I can see it both ways and really not sure which is best. I do have a slight preference towards not slowing down the happy path, particularly since this is largely a perf-motivated proposal. One possibility for now is that we can document this as a discussion point (creating a tracking issue) and discuss in committee... but also happy to go with whatever y'all recommend on it.
|
|
||
| ### Differences from `set` | ||
|
|
||
| Per the current definition of `TypedArray.prototype.set` in the language specification, the user code is responsible for allocating the destination `TypedArray` in advance along with calculating and updating the offset at which each copied segment should go. Allocations can be expensive and the book keeping can be cumbersome, particularly when there are multiple input `TypedArrays`. The `set` algorithm is also written such that each element of the copied `TypedArray` is copied to the destination one element at a time, with no affordance given to allow the implementation to determine an alternative, more optimal copy strategy. |
There was a problem hiding this comment.
with no affordance given to allow the implementation to determine an alternative, more optimal copy strategy
Implementations are always free to implement using any strategy which behaves as-if it was using the algorithm in the spec text. I strongly expect they'll implement this using exactly the same logic they use for TA.prototype.set.
There was a problem hiding this comment.
Will do an editorial clean up on this in a follow up pass
|
Given that the conversation appears to have settled out, I'd like to get this draft text landed. Any objections? |
|
I haven't done a detailed review and expect there will in any case be further normative changes, but this is fine as a draft for stage 2. |
3 participants
No description provided.