3

In the Mozilla Promise documentation, there is a Guarantees section:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises#Guarantees

It contains the following statement:

Unlike "old-style", passed-in callbacks, a promise comes with some guarantees:

Callbacks will never be called before the completion of the current run of the JavaScript event loop.

This makes sense to me and is the behavior I would expect, but I'm looking for some additional documentation supporting this "Guarantee".

Is there some sort of spec that explicitly documents / requires this? Is this guaranteed for any javascript runtime that provides a native Promise implementation? Is it the wild west, and you can't depend on it, etc.

Community
  • 1
  • 1
bingles
  • 11,582
  • 10
  • 82
  • 93
  • 1
    If only there were [some kind of spec](https://www.ecma-international.org/ecma-262/6.0/) that defined how ECMAScript and its built-in features worked. – JLRishe Mar 21 '19 at 20:45
  • related: https://stackoverflow.com/a/29454966/1048572, https://stackoverflow.com/q/23447876/1048572 – Bergi Mar 21 '19 at 20:48

3 Answers3

5

Is there some sort of spec that explicitly documents / requires this?

The spec used by promise libraries is the promise A+ spec. This particular requirement is number 2.2.4. Pretty much any promise library you use will obey this, though if you need to check this, there are tests which can verify compliance with the spec

More importantly, now that promises are a part of the language, native promises are governed by the ECMAScript specifications. Promises were first introduced in the 2015 edition, in section 25.4. The latest completed edition as of the time of this answer is the 2018 edition. The specific behavior you asked about is due to the section governing the .then method (found here), and the section on triggerPromiseReaction (found here). Each of those in turn references the enqueueJob operation (found here)

Nicholas Tower
  • 72,740
  • 7
  • 86
  • 98
  • 2
    ECMAScript's behavior is bound by the ECMAScript spec, not Promises/A+, and the former makes no mention of the latter. So the second half of your question is the vital part. – JLRishe Mar 21 '19 at 20:47
  • 1
    Also ES2015 might have been the first edition of the spec to describe promises, but it has since been superseded 3 times by newer versions. You might want to refer to the current normative specification. – Bergi Mar 21 '19 at 20:50
  • Thanks, i've incorporated both of your feedback :) – Nicholas Tower Mar 21 '19 at 21:02
2

Is there some sort of spec that explicitly documents / requires this?

Yes, the Promises/A+ interoperability spec requires this.

But no, that document is not normative for the native Promise implementation.

Is this guaranteed for any javascript runtime that provides a native Promise implementation?

Yes. This feature is an implicit property of the scheduling behaviour detailed in the ECMAScript specification for the native Promise object.

Is it the wild west, and you can't depend on it?

You can and should depend it. Even most non-native promise implementation guarantee this due to the popularity of the Promises/A+ spec.

Bergi
  • 630,263
  • 148
  • 957
  • 1,375
1

As with any built-in ECMAScript feature, the behavior of native promises is defined in the ECMAScript Spec.

The relevant sections in the 9th edition spec are section 25.6.5.4.1, which defines the behavior of the .then method, and section 8.4.1, which describes the EnqueueJob operation (which is used when .then is called on an already-resolved promise).

JLRishe
  • 99,490
  • 19
  • 131
  • 169