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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161021/46e3b221/attachment-0001.html>

>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. (PS on 10 April 2017: existing APIs may require `{ cancelable: true }` to return 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

>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. (PS on 10 April 2017: existing APIs may require 'cancelable: true' to return 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