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

@WebReflection 
> shouldn't .cancel() avoid the notification on console?

I don't think it generally should since it's still a rejection conceptually. It should be avoided in that specific case where the request is cancelled by the aggregation method (giving it ownership over its error state). 

@mariusGundersen 
> does Promise.resolve(42) return a pending or resolved promise?

Resolved, this is in the spec.

-----

The more I think about it the more I lean towards a different abstraction for cancellation since a promise is for a value and not about an action. A promise is simply not _expressive_ enough to denote cancellation for the same reasons progression failed. 

Then again the more I think about it the more I'm willing to compromise API goodness in order to deliver `fetch` with working promises.

What about a super dead simple approach where you can cancel a fetch returned promise but cancellation does not propagate or aggregate in any way.

```js
    p = fetch(...);
    p.cancel(); // cancels the promise
    p.then(Object).cancel(); // TypeError, undefined is not a function
    Promise.all([p]).cancel(); // TypeError, undefined is not a function
```

The cost is having to keep a reference to the original promise. If you want to add it to another promise perhaps one could monkey patch the cancel on the new chained promise.

This averts all the messy bits in the cancellation proposals since there are no tree or graph cases, there is no unexpected propagation or unexpected aggregation and so on. I'm wondering where this does not work. It seems a lot more explicit and verbose though.

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