A thenable should be synchronous? about native-promise-only

[getify]

I don't think there's a spec for Promise.resolve(..), so I don't know what it's supposed to do. It doesn't surprise me, but it bothers me, that Chrome and FF don't agree.

@domenic @briancavalier do you have any insight into this?

Promise.resolve(2) would obviously be sync, so I'm not sure why the above should be forced to be async if you are handed a synchronous thenable.

[getify]

A potentially relevant portion of the spec:

http://promisesaplus.com/#point-49:
"If x is a promise, adopt its state [3.4]: "

It's unclear to me if "adopt" must be sync, or must be async, or can be either as you see fit.

[Update] The latest ES6 spec draft says this about Promise.resolve(..). Still unclear to me the answer to your test case. Should be nailed down though one way or the other. Having them not agree is intolerable. :)

[domenic]

Oh dear. I think you found a hole in the ES6 spec. Following the spec, it should be 1; it executes the then synchronously. But, I believe it's been established in previous discussions that the result should be 0; you should never call untrusted user code (like a then method) unless the stack is clear. It is to avoid these exact scenarios where untrusted thenables can interfere with the invariants of the surrounding code, that this is included.

Opening an issue on domenic/promises-unwrapping right now. Will hopefully have a patch soon.

[briancavalier]

Yes, indeed. It absolutely should be 0. Nice find, guys.

[briancavalier]

It's unclear to me if "adopt" must be sync, or must be async, or can be either as you see fit.

Specifically to answer this: "as you see fit" Yes. Basically, you can do whatever wizardry you want as long as the stack-clearing invariant holds.

[getify]

Thanks for the clarifications and for the great bug catch! Fix incoming for this lib.