Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upSpec factoring: allow PerformPromiseThen with no capability #694
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
gibson042
Sep 17, 2016
Contributor
Isn't this problem exposed in the external Promise.prototype.then interface? Reacting without creating a new promise is also a common need for user code, and I'd hate to see a spec fix that isn't surfaced.
|
Isn't this problem exposed in the external |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
domenic
Sep 17, 2016
Member
That sounds like a new feature request; the proper procedure for those is outlined in https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md#feature-requests
|
That sounds like a new feature request; the proper procedure for those is outlined in https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md#feature-requests |
domenic commentedSep 16, 2016
PerformPromiseThen is used often to run some spec code after a promise settles. However, often what's being done is not a promise transform, but instead just some reaction to the promise. So you don't need the promise-returning behavior that
Promise.prototype.thendoes.Examples of this are in #692 and in the cancelable promises proposal at two locations: https://tc39.github.io/proposal-cancelable-promises/#sec-canceltoken.race and https://tc39.github.io/proposal-cancelable-promises/#sec-promise.withcanceltoken. In general we've been signaling this by creating a new "throwawayCapability" to pass in. As @littledan pointed out in #692, this is error prone since you need to make sure to mark the throwawayCapability.[[Promise]] as handled.
The ideal solution, in my opinion, would be to make the capability argument to PerformPromiseThen optional. In more detail: