Promise.cast and Promise.resolve

Ryan Scheel ryan.havvy at
Tue Jan 28 20:37:34 PST 2014

This seems like something that can be deferred to ES7.

On Tue, Jan 28, 2014 at 8:12 PM, Kris Kowal <kris.kowal at> wrote:

> In this case, a half pursuit of type purity is a side quest at the expense
> of users. Having two ways to resolve and two ways to observe a promise is
> unnecessarily confusing. In my experience, one method like "then", that
> unwraps recursively, and one function, like "Promise.cast", that
> automatically lifts if necessary, and "then" handlers that return into the
> waiting hands of "Promise.cast" are coherent and ergonomic. Having a choice
> between "cast" and "resolve" and a choice between "then" and "chain", will
> leave developers unnecessarily confused and worried all the while they use
> or abandon Promises as too subtle.
> For quite some time, grammarians have been losing a war to impose Latin
> purity on English, in the case of split infinitives. Not long ago, the
> famous phrase, "to boldly go", were a racy departure from convention
> because in Latin, the infinitive verb "to go", is a single word, and you
> simply would not break the word in half to put a poetic adverb between the
> syllables. English is not Latin, and JavaScript is not Haskell.
> Auto-lifting/unwrapping promises are beautiful. Purely monadic promises
> are beautifully captured by type theory. But, I would pick one or the other
> over one with multiple personalities. I would pick "Promise.cast" and
> "then", let complexity melt off the spec, and stop worrying.
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list