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

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]);
   }
   f();

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.

-Boris

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