On Jun 3, 2015, at 3:46 AM, Leon Arnott wrote:

> This reminds me: I feel like the spec should've added
> Array.prototype[Symbol.isConcatSpreadable] (value:true,
> configurable:false, writable:false), and eliminated the final
> IsArray() test from
> [22.1.3.11](https://people.mozilla.org/~jorendorff/es6-draft.html#sec-isconcatspreadable).
> Would've made the Array#concat() behaviour a little cleaner, in my
> opinion.
> 
> Unless, perhaps, the point was to leave it open and allow the end-user
> to monkey-patch it to false, thus finally "fixing" Array#concat()
> after all these years...? Was that the plan?

Exactly!  ES6 has to preserve the previous semantics for all existing programs, including programs that attempted to create Array subclasses in various ad hoc manners. 

@@isConcatSpreadable exists to allow new ES6-level array subclasses to explicitly opt-out of the legacy implicit spread behavior of concat.

Allen.

On Jun 3, 2015, at 3:46 AM, Leon Arnott wrote:

> This reminds me: I feel like the spec should've added
> Array.prototype[Symbol.isConcatSpreadable] (value:true,
> configurable:false, writable:false), and eliminated the final
> IsArray() test from
> [22.1.3.11](https://people.mozilla.org/~jorendorff/es6-draft.html#sec-isconcatspreadable).
> Would've made the Array#concat() behaviour a little cleaner, in my
> opinion.
> 
> Unless, perhaps, the point was to leave it open and allow the end-user
> to monkey-patch it to false, thus finally "fixing" Array#concat()
> after all these years...? Was that the plan?

Exactly!  ES6 has to preserve the previous semantics for all existing programs, including programs that attempted to create Array subclasses in various ad hoc manners. 

@@isConcatSpreadable exists to allow new ES6-level array subclasses to explicitly opt-out of the legacy implicit spread behavior of concat.