I love the fetch-api as well, but it doesn't allow for one to cancel the request. Which is why people want to change Promises in the first place. Because the committee in all its wisdom has specified that the fetch-api returns a promise. So the only way to make the requests of the fetch-api cancellable is to change the return type of the fetch-api. But that has been standardized to be a Promise. So now they want to change Promises to be whatever the hell they need from the fetch-api.

Do i need to cancel requests? Not really. But not being able to cancel requests is now driving a shitstorm of short-sighted proposals to mutate the Promise contract into some sort of 'whatever the hell the fetch-api really needs reply object'.

There's probably a (hypothetical API) way to get a _fetch_ to be cancellable, even though it returns a promise, without altering the API of general promise. Some way to get a reference to the request going on and cancel it, which would result in the promise failing (assuming it hadn't completed yet) with a FetchCancelledError or something. One could certainly imagine building such an API if one were polyfilling fetch onself built on XMLHTTPRequest (which can be cancelled).

I won't bother trying to think it through though cause it's clearly pointless except as an intellectual exersize!

I actually like that fetch returns a Promise, I find it convenient, I don't think it was a bad choice at all. To make Promise part of ES6 as a general-purpose async primitive, and to make Fetch return one. I also see how it would be nice to allow fetches to be cancelled -- although I'm not sure I've ever needed/wanted to do that, I could see how I might in the future.

It is boggling that a bunch of smart interested people haven't been able to figure out _some_ solution to this.