Re: [fetch] Aborting a fetch (#27)

fair enough, it seems more practical and more friendly. I just usually prefer knowing what's going on that if I invoke cancel I expect a rejection while you are assuming that if you have `Promise.all([CancellablePromise.resolve("hey"), CancellablePromise.resolve("hey"), CancellablePromise.resolve("hey")]).cancel()` that should silently keep going because there was nothing to cancel ... right ?

At this point we can have a `.cancel()` noop by default in the prototype for every Promise, even if no cancelability has been provided.

I have one last concern, that I have already privatly solved ... if a cancelable Promise returns inside a `then` another cancelable Promise, should the last cancel eventually cancel this one, instead of the original one that generated the chain?

```js
// how it is now
var a = new Promise(function (s, j, c) {
  var t = setTimeout(function () {
    console.log('a');
    s('a');
  }, 1000);
  c(function () {
    clearTimeout(t);
    console.log('a has been canceled');
  });
});
var b = a.then(function (a) {
  // if this is returned
  // should it be cancellable ?
  return new Promise(function (s, j, c) {
    var t = setTimeout(function () {
      console.log('b');
      s('b');
    }, 1000);
    c(function () {
      clearTimeout(t);
      console.log('b has been canceled');
    });
  });
});
var c = b.then(function (b) {
  console.log('c');
});

// after `a` and `b` won't be canceled
setTimeout(c.cancel, 1500);

// try this to cancel `a` instead
// setTimeout(c.cancel, 750);
```

Locally I have a slightly modified version that in case a cancelable Promise is returned, upgrade the chain so whoever cancel will cancel the last cancelable in the chain.

This seems like a better/least-surprise behavior to me. Thoughts?

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/27#issuecomment-88114297