Killing `Promise.fulfill`

Domenic Denicola domenic at domenicdenicola.com
Mon Aug 19 11:13:23 PDT 2013


In https://mail.mozilla.org/pipermail/es-discuss/2013-August/032724.html (plus following errata) I created the following promise:

```js
var foreverPending = new Promise(() => {});
var acceptedButNotResolved = Promise.fulfill(foreverPending);
```

This brings up the horrible point that `Promise.fulfill(foreverPending)` creates a promise that is pending, not fulfilled. Argh!

There's also the issue that the distinction between accepted and resolved is not very useful. They are only distinguishable by flatMap, not by then, and the distinction that flatMap can make is confusing and doesn't seem to buy anything.

Tab and I think the solution to this is to:

- Kill `Promise.fulfill`, and of course also the `fulfill` option to the promise initializer.
- Change `flatMap` to operate on resolved values, so that `Promise.resolve(foreverPending).flatMap(x => assert(x === foreverPending))` works.

This removes the "accepted" state entirely. It means `flatMap` effectively becomes a method for peeking into resolved promises and seeing what they are resolved to.

This also opens up the possibility of making the promise constructor go back to `new Promise((resolve, reject) => ...)`, in alignment with Promises/A+ and symmetric with `then`. The current asymmetric choice of `new Promise(({ resolve, reject, fulfill }) => ...)` has always felt unfortunate to me.



More information about the es-discuss mailing list