W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 08 May 2013 14:18:59 -0400
Message-ID: <518A9713.1070409@mit.edu>
To: "public-script-coord@w3.org" <public-script-coord@w3.org>
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.

I believe this will completely align the observable behavior of the two 
and the capabilities available to both JS functions and C++ 
implementations of WebIDL functions in terms introspecting the 
arguments.  The mental model is "undefined should act just like not passed".

In trailing position that means you can in fact omit the arguments, or 
pass undefined, and you get the same arguments.length either way, and 
the same default-value handling.

In non-trailing position you have to explicitly pass undefined to get 
the default, unless we grow named-argument passing a la python.  If we 
do, it would still be compatible with the above proposal, I believe, 
though at that point arguments.length and indexing into arguments might 
need a bit more discussion.  ;)

Thoughts?

-Boris
Received on Wednesday, 8 May 2013 18:19:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC