Killing `Promise.fulfill`

Domenic Denicola domenic at domenicdenicola.com
Tue Aug 20 07:27:54 PDT 2013


From: annevankesteren at gmail.com

> In particular, what *kind* of unwrapping does then() do on the input and return side (ideally expressed in pseudo-code).

I believe this comes down to the as-yet-unresolved conversation about thenable assimilation vs. branding and such. In any case, it should be recursive, if that helps.

> And what's the state of a promise that's .resolve()'d with a promise-like or a promise? "pending" I guess?

It depends on the state of the promise, or the behavior of a promise-like. Resolving P with a pending promise makes P pending; resolving P with a fulfilled promise makes P fulfilled; resolving P with a rejected promise makes P rejected. The behavior for thenables is similar but of course involves more trickery to defend against e.g. throws or multiple calls.

However, note that "state" is an emergent concept in the delayed-unwrapping paradigm. It's not really something you can divine inherently, at least, not if thenables are involved. Speaking somewhat imprecisely, `p` is fulfilled if `p.then(f, r)` will call `f` as soon as possible; it is rejected if `p.then(f, r)` will call `r` as soon as possible; and it is pending if `p.then(f, r)` will call neither `f` nor `r` within an even loop turn.

If you deal only with promises, where the implementation can synchronously inspect the internal state of the promise, then you can make a guaranteed-accurate determination of which of these will happen (i.e., if P is resolved to Q, P's state is equal to Q's state; continue recursively until you reach a promise that is not resolved to another promise). But since thenables do not allow such synchronous inspection, if they are included in the model then codifying state accurately is not possible, and it would be best to leave state as an implicit concept and not try to include it in a formal specification.



More information about the es-discuss mailing list