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.then does.
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:
- Change the definition of the [[Capability]] field of PromiseReaction records to allow undefined
- In PerformPromiseThen, mark resultCapability as optional, and add a line saying that if it's not provided, it gets set to undefined. (I think that's how we handle optional args to abstract ops...)
- In PromiseReactionJob, before "If handlerResult is an abrupt completion", add an "Assert: if promiseCapability is undefined, handlerResult is not an abrupt completion." (I.e., specs using PerformPromiseThen must never throw an error in their fulfill/reject handlers.) Then, if promiseCapability is undefined, return NormalCompletion(undefined) instead of doing the rest of the steps.
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: