This ordering of `console.log` calls seems to happen because
`Promise.prototype.finally` is specified in terms of
`Promise.prototype.then`, and is required to call `.then` twice.
Note the `Invoke(promise, "then", « thenFinally, catchFinally »)` here
by `Invoke(promise, "then", « ... »)` here
<https://tc39.github.io/ecma262/#sec-thenfinallyfunctions> (and here
Any way you cut it, this adds an extra asynchronous
tick/step/hop/skip/jump, compared to merely calling
Implementing `Promise` extensions in terms of `Promise.prototype.then` is a
good idea, because it means we don't have to add new fundamental operations
to the core `Promise` implementation. However, the translation from
`.finally` to `.then` comes at a cost. Once you understand that tradeoff,
hopefully this behavior seems more reasonable.
His errors are volitional and are the portals of discovery.
-- James Joyce
On Fri, Feb 23, 2018 at 9:32 AM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> On 2/23/18 9:30 AM, Michael Luder-Rosefield wrote:
>> Whenever you chain a promise with a then/finally, you're basically
>> letting the runtime look at the callbacks at some arbitrary point in the
>> future, no?
> Not if the promise is already known to be resolved. In that case, the
> exact behavior of the runtime is very clearly specified.
> es-discuss mailing list
es-discuss mailing list