Re: Fixing `Promise.resolve()`

Revised definition of Promise.resolve: 25.4.4.5Promise.resolve ( x ) The resolve function returns either a new promise resolved with the passed argument, or the argument itself if the argument is a promise produced by this constructor. 1. Let C be the this value. 2. If

RE: Fixing `Promise.resolve()`

From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] I don't think we discussed the possibility of Promise subclasses with different promise signatures at the May meeting; we mainly focused on the expectation that SubPromise.resolve(x) should yield an instance of SubPromise. Yeah, and to

RE: Fixing `Promise.resolve()`

Yes, I read that thread and still stand by my position. From: canan...@gmail.com [mailto:canan...@gmail.com] On Behalf Of C. Scott Ananian Sent: Wednesday, June 10, 2015 11:39 To: Domenic Denicola Cc: Allen Wirfs-Brock; Axel Rauschmayer; Mark S. Miller; es-discuss list Subject: Re: Fixing

Re: Fixing `Promise.resolve()`

On Jun 10, 2015, at 8:22 AM, Domenic Denicola wrote: 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

RE: Fixing `Promise.resolve()`

Subject: Re: Fixing `Promise.resolve()` I don't agree that @@species is useful at all for changing constructor signatures, since there is no closure argument. If we had dynamically scoped variables, then: ``` LabelledPromise[Symbol.species] = function() { return LabelledPromise.bind(label

Re: Fixing `Promise.resolve()`

@Domenic: please see the previous discussion at https://esdiscuss.org/topic/subclassing-es6-objects-with-es5-syntax#content-50 since there is much more discussion back-and-forth there. And you are correct about Promise.reject; Allen is proposing to remove the @@species from that method as well.

Re: Fixing `Promise.resolve()`

On Wed, Jun 10, 2015 at 11:46 AM, Domenic Denicola d...@domenic.me wrote: Regardless of whether or not you agree, that was the original motivation for its introduction. https://twitter.com/awbjs/status/535962895532584960 says: ES6 final tweaks #8: Smalltalk-like species pattern used in

Re: Fixing `Promise.resolve()`

I don't agree that @@species is useful at all for changing constructor signatures, since there is no closure argument. If we had dynamically scoped variables, then: ``` LabelledPromise[Symbol.species] = function() { return LabelledPromise.bind(label/*dynamically scoped*/); }; function() {

Re: Fixing `Promise.resolve()`

Independent of the current issue, I just want to go on record stating that dynamically scoped variables are a cure worse than any disease we might think to apply them to. Avoid at all costs. On Wed, Jun 10, 2015 at 8:44 AM, C. Scott Ananian ecmascr...@cscott.net wrote: I don't agree that

Re: Fixing `Promise.resolve()`

On Jun 10, 2015, at 9:16 AM, C. Scott Ananian wrote: On Wed, Jun 10, 2015 at 11:46 AM, Domenic Denicola d...@domenic.me wrote: Regardless of whether or not you agree, that was the original motivation for its introduction. https://twitter.com/awbjs/status/535962895532584960 says: ES6

RE: Fixing `Promise.resolve()`

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

Re: Fixing `Promise.resolve()`

Is there any way to find out how this works *now*? I can’t find the May 2015 meeting notes, either. Do all static Promise methods now just use `this` (e.g. `Promise.all()` → `this.promiseResolve(···)`)? Or only `Promise.resolve()`? Thanks! Axel On 02 Jun 2015, at 23:28, Allen Wirfs-Brock

Re: Fixing `Promise.resolve()`

Thanks! It looks like core-js has already patched in the new spec: https://github.com/zloirock/core-js/issues/75 I've opened https://github.com/paulmillr/es6-shim/issues/344 on es6-shim, and I'll see if I can get a patch together for it. I've filed

Re: Fixing `Promise.resolve()`

Hi Scott, If the change is as simple as it appears, it seems it will go into ES6 itself! Thanks for pushing this forward. On Tue, Jun 2, 2015 at 1:25 PM, C. Scott Ananian ecmascr...@cscott.net wrote: Thanks! It looks like core-js has already patched in the new spec:

Re: Fixing `Promise.resolve()`

On Jun 2, 2015, at 2:01 PM, Mark S. Miller wrote: Hi Scott, If the change is as simple as it appears, it seems it will go into ES6 itself! The fix has already been made to the production copy that will be released in a couple weeks when we have ECMA GA approval Allen Thanks for

Re: Fixing `Promise.resolve()`

At the May 27-29 TC39 meeting we agreed to make this change. Allen 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

Fixing `Promise.resolve()`

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: