Re: [whatwg/fetch] Aborting a fetch: The Next Generation (#447)

> I don't see how this is an unacceptable breaking change, whereas breaking all current code using fetch is acceptable.

What I would find "more acceptable" is that existing code **had** to change so that developers had to decide intentionally if they want to share the cancel capability explicitly or not. Affirmatively deciding on that point is better for design/architecture of code than just having things silently and accidentally permeate. I do understand the pain of breaking existing code. But sometimes pain leads to better code.

Extending the existing promise that's already being shared around by a lot of code is "pit of failure" design IMO because it means that the cancelation capability is now being shared automatically, without any code changes. That means that of all the consumers of a promise from `fetch(..)`, only one of them has to decide it wants to act extra in doing a cancelation, and all the other consumers of that promise are, without any code change, now broken/affected.

> I really don't think we need to retread this ground here, it's all in the other thread.

OK, fine. I'll drop it. But in my reading of this thread, I didn't see anyone actually addressing the concerns I have here. That's why I spoke up.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/447#issuecomment-275112387