Thank you for your interest in my proposal. :D

I also thought so and I posted [an older version of my proposal on June](https://github.com/tc39/proposal-cancelable-promises/issues/22) there. I got this answer:

>This is a separate proposal, and not an issue with the proposal being developed in this repo. So, I'll close this issue. You're welcome to continue using it as a discussion thread for your proposal, but in general there are better places to do that, such as es-discuss or your own GitHub repo you created for your proposal.

Thus I’m posting this here separately to gain attention and discuss.

From: Marky Mark<mailto:mark at heyimmark.com>
Sent: Wednesday, October 19, 2016 11:20 AM
To: Kagami Rosylight<mailto:saschanaz at outlook.com>; es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>
Subject: Re: Alternative way to achieve cancelable promise

I must admit that I do like this approach, however I'm not too familiar with the proposed spec to definitively comment on this. Have you tried proposing this in the https://github.com/tc39/proposal-cancelable-promises repository? That may be a better avenue for your suggestions.

On Sat, Oct 15, 2016 at 3:15 AM Kagami Rosylight <saschanaz at outlook.com<mailto:saschanaz at outlook.com>> wrote:
I want to find a way to replace cancellation token in the current [stage 1 cancelable promise proposal](https://github.com/tc39/proposal-cancelable-promises) with an alternative way which does not require passing an additional parameter.

Here is a short representation of [my current thought](https://github.com/SaschaNaz/cancelable):

```ts
// A cancelable object supports new `Symbol.cancel`.
// `object[Symbol.cancel]()` will cancel any tasks related to the object.
interface Cancelable {
  [@@cancel](): void;
}

interface Promise extends Cancelable {}
```

```js
// Here, a new `chain` object from promise constructor callback will
// help chaining cancelable tasks and provide cancellation related
// helper functions.

function foo() {
  return new Promise(async (resolve, reject, chain) => {
    await nonCancelableSubWork1();
    chain.throwIfCanceled(); // This line will throw `Cancel` object if the promise got a cancellation request
    await nonCancelableSubWork2();
    resolve();
 });
}

function bar() {
  return new Promise(async (resolve, reject, chain) => {
     // This `chain()` call will register foo() to the cancellation chain of a promise instance
     // and will propagate cancellation to the chained tasks.
     // The chain can receive any object that supports `Symbol.cancel`.
     await chain(foo());
     await chain(baz());
 });
}

const promise =  bar();
promise.cancel(); // This will cancel `bar` call and the cancellation will propagate to `foo` and `baz`
```

And with some syntax sugar for readability:

```js
cancelable function foo() {
  // `chain` is a keyword inside cancelable function blocks
  await nonCancelableSubWork1();
  chain.throwIfCanceled(); // similar form like `new.target`
  await nonCancelableSubWork2();
}

cancelable function bar() {
  chain foo();
  chain baz();
}

const promise = bar();
promise.cancel();

cancelable function baz() {
  try {
    chain baw();
  }
  else {
    // try-else block will catch cancellation, as the current existing proposal does
  }
}
```

I think this will achieve easier and more readable flow of cancelable tasks, what do you think?
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
--

mark

Sent while riding a hoverboard...
heyimmark.com<http://heyimmark.com> :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161019/55ceb682/attachment.html>

Thank you for your interest in my proposal. :D

I also thought so and I posted [an older version of my proposal on June](https://github.com/tc39/proposal-cancelable-promises/issues/22) there. I got this answer:

>This is a separate proposal, and not an issue with the proposal being developed in this repo. So, I'll close this issue. You're welcome to continue using it as a discussion thread for your proposal, but in general there are better places to do that, such as es-discuss or your own GitHub repo you created for your proposal.

Thus I’m posting this here separately to gain attention and discuss.