Hopefully everyone has had a little bit of time to think over the issues with Promise.resolve().
Last week I proposed three different reasonable semantics for `Promise.resolve`, none of which involve the `[[PromiseConstructor]]` internal field: https://esdiscuss.org/topic/subclassing-es6-objects-with-es5-syntax#content-50 I continue to feel that the "no species" proposal is the best alternative, reasoning that `Promise.resolve` is more like an explicit constructor than an species-using instance-transformation method. Here's that proposal again: > Promise.resolve(x) > 1. Let C be the this value. > 2. If IsPromise(x) is true, > a. Let constructor be the value of Get(x, "constructor"). > b. ReturnIfAbrupt(constructor) > c. If SameValue(constructor, C) is true, return x. > 3. Let promiseCapability be NewPromiseCapability(C). > 4. ReturnIfAbrupt(promiseCapability). > 5. Let resolveResult be Call(promiseCapability.[[Resolve]], undefined, «x»). > 6. ReturnIfAbrupt(resolveResult). > 7. Return promiseCapability.[[Promise]]. All mentions of [[PromiseConstructor]] should then be garbage-collected from the spec. This simplifies the semantics and fixes the "hidden new.target" brokenness which affects interoperability with code written in ES5 syntax. Eliminating "species" here also yields more useful behavior from `P.resolve` if an subclass sets `P[Symbol.species] !== P`. It's my understanding that Mark Miller volunteered to champion the changes to `Promise.resolve` at the next TC39 meeting. (Thanks, Mark!). I'll update `es6-shim` and `core-js`/`babel` if/when TC39 reaches consensus on this. Thanks! --scott _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
