RE: Promises "if not omitted" language

FWIW I think there are two coherent choices here: `undefined`/function only, or anything allowed, with non-functions triggering the default behavior. Allowing `null` to trigger the default behavior, but not anything else, is an antipattern that DOM specs in particular have perpetuated, and shouldn't be continued.

There is precedence for both in the ES5 spec. `Array.prototype.sort` throws a TypeError on non-`undefined`/functions, while `JSON.parse` and `JSON.stringify` ignore any non-functions.

In any case, the current spec needs to be changed to return a rejected promise instead of throwing upon bad argument mismatch. Ideally this would get fixed in WebIDL via some kind of clause "if the function returns a promise and is specified to throw an error, instead return a promise rejected with that error as the reason." Until then we'll probably need to update the spec to use `any` as the argument type and perform argument validation manually.

Received on Monday, 22 July 2013 16:15:08 UTC