you just need new syntax to kick off the chain, and you can have `task` produce a tuple of (Promise, CT) w/o leaking everywhere
-
-
Replying to @wycats
you can also allow funcs to override propagating w/ somethg like await.cancel = null (or a different CT) also w/o worse defaults
1 reply 0 retweets 1 like -
Replying to @wycats
I like. If you bottom out on a hand-rolled promise, it can presumably just capture await.cancel and wire up a callback on the token.
1 reply 0 retweets 1 like -
-
Replying to @wycats
it could be passed into the promise constructor potentially for the last mile. Tricky to cross the lang/lib divide.
1 reply 0 retweets 1 like -
Replying to @wycats
I think some people don't like await.cancel being available in all functions (I don't mind).
2 replies 0 retweets 1 like -
Replying to @wycats
I understand separable capabilities. But I'd argue an awaits function already controls resolve/reject "outcomes" so cancellation ok.
1 reply 0 retweets 0 likes -
Replying to @funcOfJoe @wycats
One subtle distinction is that the token could be remembered beyond the call. In that way, maybe diff't than resolve/reject.
1 reply 0 retweets 0 likes -
Replying to @funcOfJoe
await.cancel is just the receiving end right? No new caps.
1 reply 0 retweets 0 likes -
Replying to @wycats
Ah yes, of course. The only new "ability" of callees would be subscribing to cancellation, which seems harmless...
1 reply 0 retweets 0 likes
passing it into the function constructor would be passing the sending side in (the capability).
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.