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.
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. Regarding, parameters without default value initializers that follow parameters with default value initializers. The draft ES6 spec. says that such parameters are treated as if they had an initializer of the form "=undefined". Concretely: function f(a=42,b,c) {}; is exactly equivalent to: function f(a=42,b=undefined, c=undefined) {}; Note that if a is "optional" then b and c most also be considered "optional" because if a is not present, then b and c can not be present. EG, this is not legal ES: f( , 43, 44); This is also something that was discussed on this list in the past, and that discussion lead to the current design. Regarding built-ins, the main issue that I consider outstanding concerns some of the legacy built-ins. I would like to restate all of the function signatures in chapter 15 using ES formal parameter conventions. However, some of the legacy built-ins have lengths that don't follow the ES6 conventions 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. 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. 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. Allen
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
