Compatibility of third parameter for then method

[bergus]

A third parameter in the then method can be already found in a multitude of existing promise libraries, often being used for progress events. Has interoperability between those libraries and the proposed ES promises (that would pass a cancel callback in the thenable assimilation process) been evaluated?

[shicks]

Another concern is that a lot of promise-using code counts on the guarantee that if you write promise.then(good, bad) that exactly one of either good or bad is guaranteed to execute once promise settles. With the third state, this guarantee is lost, and so we're likely to see a proliferation of promises that are unintentionally left pending forever—which is a difficult issue to debug.

[ljharb]

@shicks yes but there's no guarantee that promise ever settles - that's why the third state isn't a breaking change. ex const promise = new Promise(() => {})

[shicks]

No, that's not a guarantee. But if one is careful, one can write code that does have that guarantee. The primary way of doing this is to use well-tested libraries and facilities like Promise.race, Promise.all, Promise.prototype.then, etc - these all have guarantees that if one or all of their inputs settle then the output will also settle. A careful developer will rely on these APIs so that they only need to be especially wary when they call new Promise(). But this change will break those guarantees in an API that doesn't (or forgets to) add the third parameter.

[ljharb]

You can still have that guarantee. Only the creator of the promise can cancel it - so if you make a promise that only ever resolves or rejects, then that guarantee won't change with this proposal.

[domenic]

New approach does not experience this (non-)issue, so closing.