Remove TypedArray.prototype.toSpliced (as discussed in plenary)

[syg]

I completely missed this during Stage 3 reviews, apologies. There is no TypedArray.prototype.splice. Why do we have a TypedArray.prototype.toSpliced?

[acutmore]

Most likely added for consistency, to keep TA methods from drifting away from Array. But I’m happy to remove as this is a complicated method which could be risky to implement for TA.

[ljharb]

good catch. splice is horrific, and toSpliced shouldn't have to exist anywhere splice doesn't already.

[zloirock]

The prior art here is Tuple, not Array - https://tc39.es/proposal-record-tuple/#sec-tuple.prototype.toSpliced. .splice is not available on %TypedArray% since the .length of instances can't be changed, like in Tuple.

[nicolo-ribaudo]

I agree with @zloirock: the reason TypedArrays don't have .splice does not apply to .toSpliced, in the exact same way Tuples have .toSpliced but not .splice. One of the goals of this proposal is to give a common interface to the various array-like objects/primitives: "this method is present everywhere" gives more benefits than the confusion caused by "this thing only has the immutable version and not the mutable one".

That said, we have added TypedArray.prototype.toSpliced for consistency but we never saw a real use case: probably few people would be unhappy if it was removed.

@syg Did you open this issue only because of the "splice is missing, toSpliced is present" inconsistency, or do you believe it could cause problems (maybe possible security bugs)?

[zloirock]

@nicolo-ribaudo I can't understand, what's the problem with real use cases of TypedArray.prototype.toSpliced? It's absolutely similar to the use cases of .splice / .toSpliced on usual arrays.

I usually use typed arrays instead of usual arrays when values should have a required number type. For example, I have an array of uint32 ids and wanna remove or replace some values in the middle - .toSpliced is the best option here. IIRC I added this example already some times.

[syg]

@syg Did you open this issue only because of the "splice is missing, toSpliced is present" inconsistency, or do you believe it could cause problems (maybe possible security bugs)?

I opened this issue because of the inconsistency, yeah. I don't buy the "consistency with Tuple" argument because, well, Tuple doesn't exist yet. So until it does, the only other sensible consistency is the presence of by-mutation versions, which this breaks.

If there are use cases, that's a fine enough reason to keep. I see some use cases for @zloirock, though I don't see how that argues for TypedArray#toSpliced any more than it does for TypedArray#splice, other than that this proposal happens to have added toSpliced.

If we keep it, we need to apply the "convert items up front" change we did to with as well, for the same reasons.

Edit: Are champions fine with a quick (15m) plenary item at the next meeting to try to re-affirm the inclusion of this?

[littledan]

To be concrete, the reason TypedArray.prototype.splice doesn't exist is because TypedArrays have fixed length, whereas TypedArray.prototype.toSpliced does not face that restriction. In general, TypedArrays were designed to have all of the Array methods which respect the restrictions that TypedArrays have (e.g., fixed length and type), without much apparent regard to utility if you look at the other methods. So I'd say, the overriding argument in favor of creating this method is consistency with Array, not Tuple. Tuple is mostly useful for reference to show the analogy that it's OK to have this method even without TypedArray.prototype.splice existing.

[zloirock]

@littledan I agree with you, but in this case, %TypedArray%.prototype.{ group, groupToMap } should be returned to https://github.com/tc39/proposal-array-grouping

[littledan]

For the record, I'm fine with saying, "We now disagree with the ES6 goal of making TypedArrays analogous to Arrays in their methods where possible; we only want to include useful methods". This reasoning would be an acceptable basis for excluding this method IMO.

[acutmore]

There is some precedent for TypedArrays not having Array methods with Array.prototype.flatMap. Though perhaps for a different reason to what we are discussing here? flatMap would need to buffer all the lists returned by the mapping function until it finishes, only then can it know the final length and attempt to allocate the ArrayBuffer and transfer the buffered items in. Combined with flat also not making sense for TypedArrays was presumably sufficient motivation to not add flatMap.

[acutmore]

For clarity: the champion group plan on keeping toSpliced on TypedArrays with the suggested modifications (#91, #92). We will bring attention to this at the upcoming July plenary meeting.