Function.length and Default Parameters
brendan at mozilla.org
Mon Oct 15 14:36:43 PDT 2012
Allen Wirfs-Brock wrote:
> We made a decision about Function length and default parameters in the
> past and I don't see a compelling reason to change that decision now.
I'm ok with that, so (IEEE754 nod): +0.
> The plan of record doesn't impact the node use case that Kevin
> identified as they specify that 4 non-optional parameters are required
> and we aren't making any changes in the counting of non-optional
> parameters for length purposes. Passing callback functions with
> optional parameters in those corresponding argument positions wouldn't
> make sense because the call backs are always called using a fixed set
> of arguments. See http://www.wirfs-brock.com/allen/posts/166 for a
> discussion of the hazards of mixing callee optional and caller
> optional function signatures.
> For example, Array.prototype.slice has a legacy length of 2 but its
> signature would be best expressed as:
> Array.prototype.slice(start, end=this.length)
> which using the ES6 function length rules would have a length of 1.
A common use of slice is to clone an array-like as a real array:
.slice.call(arguments) is calling with zero actual parameters. So one
could argue that slice's signature is actually
But we can farble it somehow to preserve compatibility, or break if
anyone really thinks we should try to roll those dice (I don't see much
> push has a legacy length of 1 while it signature would be best
> expressed as:
> Array.prototype.push (...items)
> which ES6 says has a length of 0.
By far the most common use-case is to push one value, so for legacy's
sake, if not clarity's sake:
> Among other things, differences between the generated length property
> values of ES code functions (note this is a non-configurable,
> non-writable property) and required specified values make it harder to
> self-host implementations of built-ins using ES code. I would like to
> change the specified lengths of all the built-ins to match the length
> that would be generated if their signature was expressed using default
> value initializers and rest parameters. I believe that we made some
> adjustments to the length of a few of the built-ins in ES5 (or
> implementations adjusted their implementations to match the spec) so I
> suspect that additional changes to the length of a few built-ins for
> ES6 would have little impact.
I'm not sure, but see above for some minor doubts about your preferred
signatures, which might dodge some compat-break risk.
More information about the es-discuss