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

> That's another way to go ... I personally don't think it's needed, if developers invoke cancel just for fun they'll have errors as soon as they encounter a non cancellable promise. 

I disagree with this. Consider the following:

```js
var p = Promise.all([
  CancellablePromise.resolve("hey"), //resolves right away
  fetch('/really/slow/url'), //resolves in less than 100ms
  fetch('/really/fast/url'), //resolves in more than 100ms
  doSomethingNonCancellable()
]).then(() => console.log('done!'));
setTimeout(() => p.cancel(), 100);
```

This will cancel the Promise.all, so `console.log('done!')` is never run. Great! But the promises inside it might have resolved or they might be pending, and cancelling them can result in different things. The first one is obviously resolved, so there is no work to cancel. The second one is also resolved, but it has done a lot of work for no reason, since the result it resolved to will never become available. Only the third one has work that can be cancelled, which will save a few CPU cycles. So what happens to the fourth one? 

If the non-cancellable promise has already resolved, then it will behave exactly like the fast url fetch, where it has done a lot of work with no observable results. But if it is still pending, then ignore whatever it resolves to and let it continue to work. What is the difference between letting a non-cancellable promise work too much and ignoring its result and cancelling a cancellable-promise after it has done a lot of work and resolved?

Cancelling a promise does not guarantee that work won't be done or that power will be saved. It will only guarantee that the promise won't resolve while it is pending. This is true both for chained promises and for parallel promises. 

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