Mark, I completely agree with you. However, I think this somewhat ignores the
issue of this thread. The problem with AP2, even completely ignoring `flatMap`,
comes when you consider the behavior of the `Promise.fulfill` method. Namely,
what does this code do?
```js
var foreverPending = new Promise(() => {});
var p = Promise.fulfill(foreverPending);
```
Because the recursive unwrapping has moved to the `then` side, we have that
```js
p.then(() => console.log("this will never be called"));
```
Such a promise `p` *cannot* be called fulfilled, if its fulfillment handler
will never be called. From existing Promises/A+ definitions, it is resolved,
but pending. Yet it was returned by `Promise.fulfill`, making that method a lie.
One could answer by saying that you should ignore `Promise.fulfill` (and the
resolver's `fulfill` callback), and this would be justifiable. Indeed, just
like `flatMap`, I expect `fulfill` to be ignored by Promises/A+ and the broader
community of promise users. But it prevents a severe pedagogical difficulty,
because on the one hand, we are telling people that the fundamental states of a
promise are fulfilled, rejected, and pending, whereas on the other hand we are
saying that `Promise.fulfill` is a broken, mis-named method that should never
be used even if you want to produce a fulfilled promise. (Or rather, especially
not then!)
As to your message, I guess it is unclear to me whether you envision
`Promise.fulfill` as part of the eventual TC39 consensus. Even if you don't, as
of now it's part of the DOM folks design, and I was hoping to stop a mistake
there as well.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
