Motivation

[domenic]

I've left the motivation sections as TODOs.

I think the templating use case, as explained by @ForbesLindesay here, is a good one.

I also think that assimilation could benefit. Currently, you can only assimilate by waiting a turn. Thus, there are usually at least two turns in consuming an assimilated promise: foreignPromise.then(deferred.resolve, deferred.reject) and nativePromise.then(...). With synchronous inspection available, the first step could be made synchronous while not losing the guaranteed asynchronicity of the second.

[domenic]

Dump from #5 (comment):

There are specific rare use cases for performance, interoperability, and even debugging that would be helped by synchronous inspection. They are rare and intended only to be used by library authors.

For example, if you are writing a templating library (or perhaps a "model" library as part of a MVC trio), you may wish to support promises as attributes of your template data. In many cases, the promises will already be fulfilled or rejected by the time you want to render things to the DOM. If so, it's much better to insert the data at the same time as the initial render, than to re-render once for each time a template attribute becomes fulfilled or rejected, or to find the location of the metamorphs you inserted and update each of them.

As another example, certain convenience methods, like Q.all, would benefit from synchronous inspection. In the case of being passed solely already-fulfilled/rejected promises, they would delay a single tick, instead of one for each promise. (See @ForbesLindesay's implementation)

Finally, certain utility methods, like Q.isFulfilled and friends, could be made to work with all types of third-party promises, instead of with just those from the implementation that provides them (in this case Q). Right now Q.isFulfilled/Q.isRejected/Q.isPending and friends consider third-party promises to be pending, always; this could be made accurate if synchronous inspection were available.

[domenic]

As another example, certain convenience methods, like Q.all, would benefit from synchronous inspection. In the case of being passed solely already-fulfilled/rejected promises, they would delay a single tick, instead of one for each promise.

In an ideal world this would not be true. Even without synchronous inspection, multiple calls to .then would place multiple handlers in the nextTick-queue, and at the end of the turn they would all be executed, with the last one noticing that all promises are fulfilled and thus fulfilling the promise returned by Q.all. Thus in total it would only take a single turn.

[ForbesLindesay]

Consider the case where you accept a promise for an array as well as an array of promises. That pushes your solution into an extra turn.

[domenic]

@ForbesLindesay it does not, if calls to nextTick within a nextTick callback still add to the current turn's queue (which is the case in Node.js >= 0.9).

[jkroso]

What's the status of this idea? Seems like there was general consensus that it was useful but I can't see any mention of it in the spec.