promises-unwrapping | The ES6 promises spec , as per September 2013 TC39 meeting | Runtime Evironment library

do something like this instead:

Here's one possible explanation.

A promise ultimately ends up fulfilled or rejected and it can be send directly to one of those states by fulfilling with a value or rejecting with a reason.

But, a promise can also be tied to another thenable and it will then track that thenable. If that thenable ends up fulfilled, this promise will be fulfilled. If that other thenable ends up rejected, this promise will be rejected.

So, with the executor, you can actually do three things:

1. Fulfill to a value (that is not a thenable).
2. Reject to a reason
3. Resolve to a thenable which will be tracked and whose ultimate disposition will be inherited by this promise.

Ahhh, but you don't need three functions to implement all this. You can do it with just two. #1 and #3 can use the same function and just vary what they pass to it (either a thenable or a non-thenable value). So, you need a verb that captures both #1 and #3. Folks have generally picked resolve as that verb. It is resolved to either a value or thenable.

So, you get new Promise(function(resolve, reject) {...});. You have to pick some word for the first function. Most people writing documentation picked resolve(). If you resolve to a non-thenable value, you get a fulfilled promise. If you resolve to a thenable, this promise will track that thenable and take on it's eventual state.