Because Promises don't need to be cancellable. This has nothing to do with promises. Fetch requests need to be cancellable. But they, in all their wisdom, decided that the fetch API returns a promise. So now promises need to become whatever the hell the fetch API actually needs to return.
You would almost think design by committee is fundamentally flawed, and design by community even more flawed.
Because the edge cases are never obvious. For every new feature the question shouldn't be "do i make 99 programmers 1% happier?", but do i make 1 programmer cry upto the point where they would stab my eyes out if they could?
We've all been that 1 programmer, and yes, i would if i could. It's a clusterfuck of bike shedding. Most new ES2016 have details that haven't been though through and will end up being hated on the same level as '==' and 'NaN'.
The dev-leads of the different javascript engines should not just be able to veto. They should be able to veto people out of the room, out of the debate. And we should celebrate it every time they take advantage of that power. Or just give up on Javscript all together and just let the rot fester.
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'.
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.
this would ironically tend to be applied to people like you
That doesn't mean it should be me dismissing that feature. But i am very much smiling that the people that should be in that room, did dismiss it.
It seems obvious to me that the 'right' way to do it is a cancelled promise is in the error state, with the error object just being a new type of error CancelledPromise or something.
But I guess once you start getting into it, this becomes less obvious?