Array.prototype.concat result length (ES5.1)

Yusuke Suzuki utatane.tea at
Thu Jul 14 05:58:10 PDT 2011

I also reported it to es5-discuss,
and got " This is a bug in the spec."

I think [[Put]]("length", {[[Value]]: n}, true) step should be
inserted to the end of this(like, pop, push method), is it correct?

On Thu, Jul 14, 2011 at 9:21 PM, Andrew Oakley <andrew at> wrote:
> I'm not sure the Array.prototype.concat algorithm (§ is quite
> right.
> As far as I can see the length property of the result (A) is not
> explicitly set anywhere in the algorithm so we are relying on the
> [[DefineOwnProperty]] method of A to set the length for us when we add
> indexed properties to it.
> If we pass "sparse" arrays to the function then I think the results
> should look like this:
> [,,,,].concat([]) => [] (length 0)
> [,x,,].concat([]) => [,x] (length 2)
> This is not what browsers do and is a significant change from ECMAScript
> 3 (which set the length of A at the end of the algorithm)
> Is it reasonable to add another step at the end of the algorithm to make
> it match browser behaviour better:
> Call the [[DefineOwnProperty]] internal method of A with arguments
> "length", Property Descriptor {[[Value]]: n}, and false.
> The other complication I've spotted (I think it crops up elsewhere too)
> is what to do if n becomes larger than the maximum array index.  My
> reading of ECMAScript 3 says that we *should* throw a RangeError but
> nobody seems to do that.
> Opera and Firefox seem to store n as a 32bit unsigned number - the
> length wraps and they start putting properties at the beginning of the
> array again.  I'm not sure what Chrome is doing (I can't find my values
> in the returned array), IE says "out of memory" and I got bored waiting
> for Safari.
> --
> Andrew Oakley
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list