Hi Bergi:
>You're not the only one who is unsatisfied with the current proposal :-) Also
>have a look at
Great! I’m yet to read them but I definitely will soon to discuss more.
>Promises are result values that can be passed to multiple consumers, and not
>every consumer should be allowed to cancel the computation. So by default,
>promises must not be cancellable.
My current updated proposal allows cancellation only for promises created by
`Promise.cancelable()` call. In this case, simple `return
Promise.resolve(cancelablePromise)` will disallow cancellation for other
consumers. But yes, this may be an opt-out rather than opt-in for APIs
returning cancelable promises.
>I don't see the major difference between these "chain" objects and "tokens"
>from the other proposals. Can you expand on that, please?
“Chain”s do not need to be passed manually. A chain will store cancelable
promises and will `[@@cancel]()` them after cancellation request. Each promise
will have its own chain which will again propagate cancellations.
>You should never pass an async function to the new Promise constructor, have a
>look here. Fortunately, the code in your actual proposal seems more reasonable
>here.
I agree that the constructor approach is not good and would break easily. Thus,
my updated proposal now uses `Promise.cancelable(async (chain) => {})` rather
than the constructor itself.
>If I understood correctly, your chain keyword could be used like await? What
>is the difference between them?
`await` will not be automatically canceled when `chain` will:
```
cancelable function saya() {
// This is theoretically cancelable but user somehow want it to be ‘atomic’.
await cancelableSubWork();
chain.throwIfCanceled();
}
```
Sincerely,
Kagami Sascha Rosylight
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
