allen at wirfs-brock.com
Tue Jun 2 01:44:11 UTC 2015
At the May 27-29 TC39 meeting we agreed to make this change.
On May 7, 2015, at 2:47 PM, C. Scott Ananian wrote:
> 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:
> 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:
>> 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,
> I'll update `es6-shim` and `core-js`/`babel` if/when TC39 reaches
> consensus on this.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss