Spec factoring: allow PerformPromiseThen with no capability

[domenic]

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.

[gibson042]

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.

[domenic]

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