State inconsistency with chained promises

[pjeby]

In general, if a promise's getState() returns FULFILLED or REJECTED, then wait() returns a value or error immediately. (i.e., you can call inspect() on a non-pending promise and get a valid answer).

But this is not the case if you resolve() or reject() with a promise -- either directly, or indirectly by returning one from a then() handler. In such a case, you can have a promise whose state is fulfilled or rejected on the surface but is actually pending internally. Thiis appears to be a violation of section 2.3.2.1 of the Promises/A+ spec, i.e. "If x is pending, promise must remain pending until x is fulfilled or rejected. But this library's promise implementation prematurely settles the promise, rather than leaving it pending per the spec.

In cases where you want to be able to poll the value of promises (but can't actually wait on them), this is a problem because there is no way to know from outside the promise that this pseudo-fulfillment condition can be detected. The only way to avoid it seems to be to either 1) exclusively use coroutines, 2) never use getState() and wait(), or 3) never call resolve() with a promise or return one from a then() handler.

ISTM that it would be better here to follow the spec, and have a promise remain pending when resolved or rejected with another promise, until such time as the other promise resolves or rejects, especially since a pending promise passed to resolve() could later reject, resulting in the paradoxical condition of a promise whose state is "fulfilled", yet throws an error when you wait() on it!