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
<https://tc39.github.io/ecma262/#sec-promise.prototype.finally>, followed
by `Invoke(promise, "then", « ... »)` here
<https://tc39.github.io/ecma262/#sec-thenfinallyfunctions> (and here
<https://tc39.github.io/ecma262/#sec-catchfinallyfunctions>).

Any way you cut it, this adds an extra asynchronous
tick/step/hop/skip/jump, compared to merely calling
`Promise.prototype.then`.

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.

Ben

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.
>
> -Boris
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to