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

On Fri, Jun 7, 2013 at 4:35 AM, Brendan Eich <[email protected]> wrote:
>> 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?

FWIW, my understanding is that there's general agreement that the way
TreatUndefinedAs is defined in the WebIDL spec is wrong and needs to
be changed. The change is to make all optional arguments by default
treat an explicitly passed 'undefined' to an optional argument as
"argment not passed". Then TreatUndefinedAs can be used to override
that where other behavior is needed (I think mostly legacy APIs, if
it's needed at all).

/ Jonas