Re: Reconciling handling of optional arguments and handling of default values across ES and webidl

On May 8, 2013, at 11:18 AM, Boris Zbarsky wrote:

> This keeps coming up, so here comes a proposal....  I believe what I'm proposing does not represent the status quo for either ES6 or WebIDL, but it seems like the sanest available behavior to me, and I'd like to see what the objections are to it.  I am aware that there has been a good bit of discussion about this in ES6, and I've read all of it that I could find, for what it's worth.  And I think that people are undecided about how exactly "optional" arguments and "default values" should work, which is leading to some wackiness.
> 
> WebIDL behavior:
> 
> 1)  Allow any argument to be marked as optional in WebIDL, even if followed by non-optional ones.
> 
> 2)  Allow any argument that is optional to have a default value provided in WebIDL, even if followed or preceded by optional arguments without default values.
> 
> 3)  Treat undefined passed for an optional argument as "not passed".  If there is a default value, the default value takes effect.
> 
> ES behavior:
> 
> 1)  Allow specifying a default value for any function argument, even if followed or preceded by arguments without default values, with the default taking effect if undefined is passed.
> 
> 2)  Have arguments.length not include trailing undefined values.

This is not how argument.length is currently specified in either ES5 or ES6.  Explicitly passed trailing undefines counts into the determination of arguments.length.  That's how JS code distinguishes between missing trailing arguments and explicitly passed undefined.  I pretty sure that changing this would break existing code including existing poly-fiils for some built-ins that are specified to distinguish the missing from undefined arguments cases.

Allen

Received on Wednesday, 8 May 2013 23:17:58 UTC