On Jul 3, 2012, at 9:07 AM, Brendan Eich wrote: > Russell Leggett wrote: >> ... >> >> >> The spec states: "When the splice method is called with two or more >> arguments..." - therefore, a.splice(2); leads to unspecified behavior.
Technically that's not correct. The introduction to chapter 15 says: "Unless otherwise specified in the description of a particular function, if a function or constructor described in this clause is given fewer arguments than the function is specified to require, the function or constructor shall behave exactly as if it had been given sufficient additional arguments, each such argument being the undefined value." So, if the second argument is not specified it is treaded as the value undefined and ToInteger(undefined) is 0. >> If you look at the MDN docs >> <https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/splice>, >> splice called with only a single argument removes until the end of the >> array, similar to the substring method. >> >> "If no howMany parameter is specified (second syntax above, which is a >> SpiderMonkey extension), all elements after index are removed." >> >> Basically, what is happening here is that everyone else accepted the >> spidermonkey extension, but technically because it is unspecified, browsers >> can do what they want and still be considered compliant. Perhaps it is >> something which should be *added* to the spec. No, technically, all the browsers except for IE deviate from the specification and it has been specified that way since the function was introduced in ES3. > > Causality was the other way, of course: I implemented splice in SpiderMonkey > in 1997 based on Perl 4: > > http://perldoc.perl.org/functions/splice.html > > and indeed it handles omitted OFFSET and LENGTH the same. IE8 is just defying > a de-facto standard, news at 11 :-P. and I have no idea why ES3 did not codify the FF implementation. Prior to the emergence of Safari and Chrome it probably would have been a stretch to say that the FF behavior was a de facto standard and it is always tricky for implementors to navigate through situations where there is divergence between the de jour and de facto standards. > > Agree we should codify this in ES6. Agreed, the ES6 standards and implementations should get aligned on this. In theory it could go either way, but in this case changing the standard to match the majority of implementations seems like the reasonable thing to do. Does somebody want to file a bug so we can track this? Allen > > /be > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
