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.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
