Clarify when `onFulfilled`/`onRejected` must *not* be called

[briancavalier]

See promises-aplus/promises-tests#36. Copied from my comment.

---

It seems there is nothing that explicitly prevents an implementation from calling onRejected between the instant a promise is fulfilled and the instant onFulfilled is called, which then makes section 3.2.2 into a contradiction: onFulfilled must be called (3.2.2.1), but also must not be (3.2.2.3)!

It also seems that there's nothing that explicitly prevents an implementation from calling either onFulfilled or onRejected while a promise is pending.

These things are certainly implied, and if an implementation chose to do them, it seems that would make it impossible (afaict) to satisfy the other requirements of the spec (specifically 3.2.2, 3.2.3 and 3.2.5).

Perhaps we need to add a few explicit statements to clarify? Something like:

• onFulfilled and onRejected must not be called while promise is pending.
• onFulfilled must not be called after promise is rejected.
• onRejected must not be called after promise is fulfilled.

Another alternative might be to add "only" to existing requirements:

• 3.2.2.1 it must be called after, and only after, promise is fulfilled, with promise’s fulfillment value as its first argument.
• 3.2.3.1 it must be called after, and only after, promise is rejected, with promise’s rejection reason as its first argument.

What do others think? Do we have some holes here we need to patch, or are the current implications strong/obvious enough?

[lsmith]

Interesting. I think a language change is reasonable. I prefer your first suggestion of the explicit bullets.

[domenic]

I'm curious whether anyone can make an implementation that follows the existing spec/passes the existing tests, but still disobeys these bullets?

[briancavalier]

@domenic I actually don't believe it's possible. The problem, though, is that the current spec simply may not be clear enough, and may cause confusion, which seems to be what happened in promises-aplus/promises-tests#36

[briancavalier]

Hmmm, what about a promise that remains pending forever? Seems the spec allows an implementation to call either onFulfilled or onRejected (but not both) once, whenever it feels like it in that case.

[domenic]

Hmmm, what about a promise that remains pending forever?

Nice catch, agreed it's a hole. Kind of a symptom of our requirements-based (as opposed to algorithm-based) spec, but what can you do.

[briancavalier]

Ok, I took a shot at it in #130. I think it's possible to specify what we want by simply changing two bullets, rather than adding more. Let me know if you think this captures what we want and also doesn't open any new holes :)