- From: Domenic Denicola <domenic@domenicdenicola.com>
- Date: Wed, 1 Oct 2014 15:44:16 +0000
- To: Tab Atkins Jr. <jackalmage@gmail.com>, Anne van Kesteren <annevk@annevk.nl>
- Cc: WHATWG <whatwg@whatwg.org>, Jake Archibald <jaffathecake@gmail.com>, Jonas Sicking <jonas@sicking.cc>, Andrew Wilson <atwilson@google.com>, Peter Beverloo <beverloo@google.com>
From: whatwg [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Tab Atkins Jr. > This is actually kinda terrible. Promises make it *really easy* to deal with rejections *later*, letting you execute a bunch of code on the success path and only at the end saying "Oh, did something along the line fail? Let me take care of that.". Promise is basically an async Maybe monad, which is great, because Maybe is useful for *exactly the scenario I just outlined*. This is exactly the wrong way to think about promises. Promises are the "async return/throw monad"; if you want a Maybe, then you have to compose that in yourself. People often try to abuse the fact that they have a second branch for exceptions in order to use it as a generic container for "go down two possible flow paths", but that is very incorrect. An earlier comment in the thread about "we have three possible mechanisms" is also symptomatic of this incorrect thinking. We have two mechanisms: return and throw. When you wrap those in async, they become fulfill and reject. > I think we should develop Promises in a way that exploits their ergonomics properly, and then rethink async/await a bit to make it match those ergonomics, rather than fighting them. We are not changing the model of promises in this way. If you want a Maybe monad, that's a separate API that you'd want to spec.
Received on Wednesday, 1 October 2014 15:44:52 UTC