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

On 6/7/13 7:35 AM, Brendan Eich wrote:
> That is, if you have ES3 or ES5 code of this form:
>
>    function f(a, b) {
>      a = a || 4;
>      b = b || 5;
>      return g.apply(undefined, arguments);
>    }
>
> The ES6 way to write it is to avoid arguments altogether:
>
>    function f(a = 4, b = 5, ...r) {
>      return g(a, b, ...r);
>    }

OK, that makes sense to me.  I'm mostly worried about impedance 
mismatches between libraries that currently use apply and arguments with 
abandon and webidl APIS, but maybe in practice this will be a nonissue....

>> 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.
>
> Ouch. But didn't TreatUndefinedAs in all its glory already do most of
> the damage?

No, the thing doing the damage here is that a C++ implementation doesn't 
really want to use "undefined" to indicate "not passed" since there is 
no such value in C++ to start with, and bridging that impedance mismatch 
ends up ugly unless the IDL is clearly annotated with the exact 
semantics undefined should have in particular cases.

-Boris

Received on Friday, 7 June 2013 16:05:05 UTC