Promise.cast and Promise.resolve

Paolo Amadini paolo.02.prg at
Tue Jan 28 12:07:02 PST 2014

[Replying here since I'm not sure about how to move the discussion to
the issue tracker without losing the context of Mark's observation.]

On 28/01/2014 20.28, Mark S. Miller wrote:
> For people concerned only about the .then level of abstraction, I see
> little reason to ever use Promise.resolve rather than Promise.cast, and
> much reason to prefer Promise.cast. But fwiw we did agree to express the
> difference now, to be perceived by future and experimental uses of
> .flatMap in the future.

I don't have a background on the .flatMap level of abstraction. In the
following scenario, will users of getMyPromise() have a different
behavior with .flatMap if the library code used "cast" rather than
"resolve"? If so, this can definitely lead to confusion when .flatMap
is introduced in the future since the callers cannot be sure about
what the library did internally, assuming the library authors didn't
intentionally choose one or the other.

// ------ MyLibrary.js

function getMyPromise() {
  var a = condition ? getMyOtherPromise() : "value2";
  return Promise.resolve(a);

function getMyOtherPromise() {
  return Promise.resolve("value1");

More information about the es-discuss mailing list