Fixing `Promise.resolve()`

Domenic Denicola d at
Wed Jun 10 15:22:11 UTC 2015

Allen, that change seems wrong. I thought we were only changing the IsPromise steps. The actual construction should still go through species. If nothing else, it should do so for consistency with reject.

The motivation of @@species, as I understood it, was to allow alternate subclass constructor signatures (originally for Array and TypedArray, but Promise can benefit as well). It’s understandable to not involve @@species when doing weak type-tests. But any time you construct a promise instance, you should go through @@species, instead of the constructor directly.

Some example usages:

- Creating a LabeledPromise subclass (for better debugging, like RSVP's promises + Ember promise inspector) whose constructor signature is `new LabeledPromise(label, executor)`
- Creating a SaneArray subclass whose constructor signature is `new SaneArray(...elements)` without the special-case for a single argument.
- A more complicated usage in a proposed Element/HTMLElement/MyCustomElement hierarchy [1], to allow custom elements to have custom constructor signatures but still work well with various element-creating parts of the platform.

The LabeledPromise case will, as currently specified, work great. LabeledPromise has a custom `LabeledPromise[Symbol.species](executor)` which basically does `return new this("<derived promise>", executor)`. Then it doesn't have to override `.resolve`, `.reject`, `.all`, or `.then`. However, with your change, `.resolve` will no longer work correctly, even though `.reject` will.

However, the SaneArray case actually will only work for the instance methods, which use ArraySpeciesCreate. In contrast, Array.of and Array.from use Construct(C, <<len>>). That seems like a bug in the spec?


More information about the es-discuss mailing list