Ecma262: Array.prototype.concat `this` value oddity

[spazmodius]

Description:
Array.prototype.concat.call(1, 2, 3) returns the value [ [Number: 1], 2, 3 ], where the first argument (the this), if primitive, has been converted to an object.

This seems like an undesirable asymmetry with the remaining arguments.

The algorithm appears to only need the object for ArraySpeciesCreate(), not for processing the list of elements.

[ljharb]

The receiver isn’t the same as an argument (although that’s one way to think of it); what symmetry would you envision?

All of the array methods, i believe, operate on the receiver in this way.

[spazmodius]

I'm imagining the desired result is an array that is composed entirely of the values, or elements thereof, that I sent into the call. However, in the case i cite, the resulting array contains a manufactured value that is nowhere to be found in my call.

[ljharb]

If you did [].concat(1, 2, 3) you’d get that (or Array.of(1, 2, 3)), but borrowing a prototype method and using .call on it isn’t something I’d consider common usage.

[spazmodius]

using .call on it isn’t something I’d consider common usage

Nor I. I just thought is was a weird leakage of the algorithm's internal temp value.

[bathos]

You’ll find this in other generic Array methods even if they don’t invoke ArraySpeciesCreate.

I’m not sure I’d consider it a leak, since concat’s apparent flexibility is what’s unusual here moreso than generic arraylike methods casting their receivers to generic arraylikes (which === 'any object').

[allenwb]

None of this is an implementation leak, rather the implementation is carefully preserving the legacy behavior from when the methods were first added to the standard. Don't break the web!