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

Re: [Futures] accept/resolve/reject on a resolver don't have clearly defined behavior if no value is passed

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 06 Jun 2013 13:18:13 -0400
Message-ID: <51B0C455.1070204@mit.edu>
To: Jonas Sicking <jonas@sicking.cc>
CC: DOM public list <www-dom@w3.org>, Anne van Kesteren <annevk@annevk.nl>, Cameron McCormack <cam@mcc.id.au>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 6/6/13 1:01 PM, Jonas Sicking wrote:
> It also has the advantage
> that the Future implementation doesn't need to spend time looking for
> 'undefined' and treating it differently.

If you mean the C++ implementation, that's ... unclear.  There is no way 
to write "optional any foo = undefined" in WebIDL, and furthermore no 
such concept in ES in general.

Which brings us to an interesting difference in default arguments 
between current WebIDL and ES, by the way.

In WebIDL, an optional argument is either "not passed" or has a value. 
Arguments with a default value are never "not passed".  For an optional 
argument of type "any", you can tell apart "not passed" and "undefined 
was passed explicitly", unless it's marked as [TreatUndefinedAs=Missing].

In ES, an argument is either "not passed" (as determined by 
arguments.length) or has a value.  Arguments with a default value can in 
fact be "not passed" in that default values do not affect the arguments 
object at all.  For example:

   function f(arg = 5) {
     alert(arg + " " + arguments[0]);

alerts "5 undefined".  Furthermore, even when an argument was passed its 
default value will still kick in if undefined is passed.

I'd like to claim that the ES semantics here where default values don't 
affect the arguments object are pretty weird and seem like a footgun 
when combined with call/apply on the arguments object, but I assume 
there's a reason for them...

In any case, the question is how to reconcile the two sanely.  Once 
that's done, I fully expect the simplicity of the C++ implementation 
here to be nonexistent.

Received on Thursday, 6 June 2013 17:18:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC