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

> I don't even care much about fetch itself in terms of solution

Right, but I think you missed my point, which is that `fetch(..)` and others have an explicit promise creation notion, so it's easier to see how the `ifCanceled` could be provided to the promise returned from `fetch(..)`, but there are other mechanisms like `async function` which implicitly create promises, and offer no such mechanism.

That's the major weakness of your idea, IMO, that it only works for explicit promise-creation tasks, but doesn't seem to work for implicit promise-creation tasks.

> providing a canceling mechanism is the only way to go

If you're talking about canceling `fetch(..)` and `async function` and other promise-creating tasks, I agree. If you're talking about canceling the promise directly, rather than indirectly by virtue of the task being canceled, I don't agree. I don't think it follows at all that promises **have** to be cancelable to achieve the clearly agreed ideals that `fetch(..)` should be cancelable.

>  if you always need boths whhy not just passing a promise with .cancel ability ?

That's precisely the point I've made many times in this thread, that you **don't always need** both, and in fact it's dangerous to system trustability to **always have both**. The advantage of the controller with separate observation and cancelability is that in places where you need both, you pass the controller, and in places where that's a bad idea, you pass only the promise (or only the cancelation).

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