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

undefined being treated as a missing optional argument

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 12 Apr 2012 10:15:35 +1000
Message-ID: <4F861EA7.3060706@mcc.id.au>
To: "public-script-coord@w3.org" <public-script-coord@w3.org>
CC: Jonas Sicking <jonas@sicking.cc>, Brendan Eich <brendan@mozilla.com>, David Herman <dherman@mozilla.com>, Sam Tobin-Hochstadt <samth@ccs.neu.edu>
A few months ago we had some long discussions about what it means to 
pass undefined as the value of an optional argument, for example:

   void f(optional long x);

called with:

   f(undefined);

What we eventually settled on was that an explicit undefined is always 
treated as a specified argument, so for the above case undefined would 
be converted to the IDL long value 0.  Here's where the original 
decision was announced:

   http://www.w3.org/mid/4EF3DB9C.4080401@mcc.id.au

Maybe the strongest reason for deciding this way was to align with how 
ES6 was going to handle function argument default values.  It's been 
brought to my attention though that this behaviour is not yet fixed for 
ES6 and there's a good possibility that ES6 will specify that passing 
undefined will cause the argument's default value to be used.  If that 
happens, then it seems like we might again want Web IDL to change to be 
consistent with that.

Unless there are any objections, I'm going to add a note to the spec to 
point out that undefined is currently not treated as a missing optional 
argument in alignment with ES6, but that ES6 may yet change and that we 
might revisit the decision at that point.

(If we did revisit the decision, there are various knock-on changes we'd 
need to make (again) such as bringing dictionaries in line by having an 
undefined value specified for a dictionary member mean that it is not 
present, ensuring that the overload resolution algorithm can handle 
this, deciding what it means to pass undefined to an optional argument 
of IDL type any, and so on.)
Received on Thursday, 12 April 2012 00:16:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:06 UTC