Function.length and Default Parameters

Brendan Eich brendan at
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 for a 
> discussion of the hazards of mixing callee optional and caller 
> optional function signatures.

Good points.

> 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: 
[] is calling with zero actual parameters. So one 
could argue that slice's signature is actually

   Array.prototype.slice(start=0, end=this.length).

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 mailing list