This is actually up for clarification in the upcoming 1.1 version of the spec. The important invariant is that the function execution stack be empty of user code at the time `onFulfilled` and `onRejected` are called. The current phrasing does not suffice for this, as pointed out in
https://github.com/promises-aplus/promises-spec/issues/100 The current phrasing is just an (insufficient) means of working around the fact that JS doesn't specify an event loop; an attempt at being clever. Discussion is ongoing at https://github.com/promises-aplus/promises-spec/pull/104 We seem to be converging around something more like the invariant I spoke of above, as prompted by Mark Miller; e.g. "`onFulfilled` or `onRejected` must not be called when the stack contains any user code." But this requires defining user code, which is tricky---it includes `[native code]`, but also base code from the platform (e.g. Node.js's built-in modules), and parts of the promise implementation itself (e.g. the internal trampolines used by Q and when among others, or the setImmediate polyfill many fall back on). _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
