Cancelable Promises: Why was this proposal withdrawn?
Promises have always been extremely contentious in JS for a couple reasons and Domenic has had the patience of a saint getting the original proposal through so it's totally understandable that he might not want to deal with this anymore especially if people in his org are against it.There were a couple reasons the original promises were so contentious to standardize.- Monads: there was a very vocal faction on TC-39 that really wanted a Promises to be monadic and very much emphasized mathematical purity over usefulness and any attempt to discuss things tended to get side tracked into a discussion about monads, see brouhaha over Promise.cast [1].- Error handling: Promises have a bit of a footgun where by default they can swallow errors unless you explicitly add a listener for them.  As you can theoretically add an error listener latter on all other options had downsides (not always obvious to advocates) leading to a lot of arguing, must of it after things had shipped and realistically couldn't be changed.  Fixed by platforms and libraries agreeing on a standardization of uncaught promise events [2].- Just an absurd amount of bike shedding probably the 2nd most bike shedded feature of the spec (behind modules).So cancelable promises reignite all the old debates plus there's no obvious right way to do it, like should it be a 3rd state which could cause compatibility issues and would add complexity, or should cancellations just be a sort of forced rejection, which would be a lot more backwards compatibility but with less features.Additionally there is a bizarre meme that somehow observables (think event emitters restricted to a single event or synchronous streams that don't handle back pressure) are a replacement for promises or are a better fit for async tasks they should be used instead.edit: patients => patience1. https://esdiscuss.org/topic/promise-cast-and-promise-resolve2. https://gist.github.com/benjamingr/0237932cee84712951a2