Killing `Promise.fulfill`

Domenic Denicola domenic at domenicdenicola.com
Mon Aug 19 18:34:24 PDT 2013


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.
 


More information about the es-discuss mailing list