<story><title>Cancelable Promises: Why was this proposal withdrawn?</title><url>https://github.com/tc39/proposal-cancelable-promises/issues/70</url></story><parent_chain><item><author>cwmma</author><text>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&amp;#x27;s totally understandable that he might not want to deal with this anymore especially if people in his org are against it.&lt;p&gt;There were a couple reasons the original promises were so contentious to standardize.&lt;p&gt;- 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].&lt;p&gt;- 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&amp;#x27;t be changed.  Fixed by platforms and libraries agreeing on a standardization of uncaught promise events [2].&lt;p&gt;- Just an absurd amount of bike shedding probably the 2nd most bike shedded feature of the spec (behind modules).&lt;p&gt;So cancelable promises reignite all the old debates plus there&amp;#x27;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.&lt;p&gt;Additionally there is a bizarre meme that somehow observables (think event emitters restricted to a single event or synchronous streams that don&amp;#x27;t handle back pressure) are a replacement for promises or are a better fit for async tasks they should be used instead.&lt;p&gt;edit: patients =&amp;gt; patience&lt;p&gt;1. &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;esdiscuss.org&amp;#x2F;topic&amp;#x2F;promise-cast-and-promise-resolve&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;esdiscuss.org&amp;#x2F;topic&amp;#x2F;promise-cast-and-promise-resolve&lt;/a&gt;&lt;p&gt;2. &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;gist.github.com&amp;#x2F;benjamingr&amp;#x2F;0237932cee84712951a2&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;gist.github.com&amp;#x2F;benjamingr&amp;#x2F;0237932cee84712951a2&lt;/a&gt;</text></item></parent_chain><comment><author>spion</author><text>The problem wasn&amp;#x27;t usefulness or purity, it was that the community already standardised on a certain behaviour of promises that was not monadic. The only way to make promises monadic was to therefore not standardise &amp;quot;promises&amp;quot; at all.&lt;p&gt;At that time, monadic tasks were basically unheard of in the community. By the very nature of the monad laws, they cannot have side-effects, so they cannot be eager. This means that a user &amp;quot;running&amp;quot; an operation would observe nothing until they subscribe to it. In an imperative language like JS, this is confusing for users, and arguably not worth the breakage of the existing promise ecosystem.&lt;p&gt;Another nice property of Promises is that they can be implemented in a way that doesn&amp;#x27;t cause stack overflow for endeless recursion (and additionally, in some cases we can get &amp;quot;tail recursion&amp;quot;). This might be doable with lazy tasks too - not entirely sure. See &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;paf31&amp;#x2F;purescript-safely&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;paf31&amp;#x2F;purescript-safely&lt;/a&gt;&lt;p&gt;On the other hand, monadic tasks make many other things easier, like&lt;p&gt;* cancellation (just unsubscribe),&lt;p&gt;* synchronous error propagation, so no issues with error swallowing and perhaps no post-mortem issues in node. Nothing runs before the subscription, so at the point the side effects are running, we already know whether there is an error handler. Effectively the `done` method would&amp;#x27;ve been the eqiuivalent of `subscribe`, and mandatory&lt;p&gt;* defining parallel, sequential or limited-concurrency execution order after the tasks have been created</text></comment>
<story><title>Cancelable Promises: Why was this proposal withdrawn?</title><url>https://github.com/tc39/proposal-cancelable-promises/issues/70</url></story><parent_chain><item><author>cwmma</author><text>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&amp;#x27;s totally understandable that he might not want to deal with this anymore especially if people in his org are against it.&lt;p&gt;There were a couple reasons the original promises were so contentious to standardize.&lt;p&gt;- 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].&lt;p&gt;- 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&amp;#x27;t be changed.  Fixed by platforms and libraries agreeing on a standardization of uncaught promise events [2].&lt;p&gt;- Just an absurd amount of bike shedding probably the 2nd most bike shedded feature of the spec (behind modules).&lt;p&gt;So cancelable promises reignite all the old debates plus there&amp;#x27;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.&lt;p&gt;Additionally there is a bizarre meme that somehow observables (think event emitters restricted to a single event or synchronous streams that don&amp;#x27;t handle back pressure) are a replacement for promises or are a better fit for async tasks they should be used instead.&lt;p&gt;edit: patients =&amp;gt; patience&lt;p&gt;1. &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;esdiscuss.org&amp;#x2F;topic&amp;#x2F;promise-cast-and-promise-resolve&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;esdiscuss.org&amp;#x2F;topic&amp;#x2F;promise-cast-and-promise-resolve&lt;/a&gt;&lt;p&gt;2. &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;gist.github.com&amp;#x2F;benjamingr&amp;#x2F;0237932cee84712951a2&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;gist.github.com&amp;#x2F;benjamingr&amp;#x2F;0237932cee84712951a2&lt;/a&gt;</text></item></parent_chain><comment><author>koolba</author><text>&amp;gt; Promises have always been extremely contentious in JS for a couple reasons and Domenic has had &lt;i&gt;the patients of a saint&lt;/i&gt; getting the original proposal through so it&amp;#x27;s totally understandable that he might not want to deal with this anymore especially if people in his org are against it.&lt;p&gt;I know this is probably a typo (patients =&amp;gt; patience) but that spelling seems to work as well.&lt;p&gt;&amp;gt; So cancelable promises reignite all the old debates plus there&amp;#x27;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.&lt;p&gt;IMHO neither as cancelability isn&amp;#x27;t a common requirement. People that need it tend to have more complex requirements and end up tying the cancellation to other chains of logic anyway. Also, unlike say catching an error, you generally want all cancellation handlers to fire rather than just the first one (like with errors).</text></comment>