Re: [ServiceWorker] Changing Request and fetch() (#625)

I think subclassing promises should be done with care but isn't necessarily incompatible with async/await. That is, you can do

```js
const inProgressFetch = fetch(req);

// Do other stuff, possibly async...
const otherInfo = await someOtherStuff();

if (otherInfo.shouldCancel) {
  inProgressFetch.cancel();
  return;
}

const response = await inProgressFetch;
```

That said, I think it would require some concerted all-hands-on-deck API design to come up with the correct semantics for cancelable promises in the timeframe we seem to be working on, here.

I also wanted to put out there as an option the following syntax:

```js
const inProgressFetch = fetch.controllable(req);
```

Maybe in this example `inProgressFetch` is @wanderview's `{ abort(), changePriority(), port, ready }`.

Finally regarding the names "abort" vs. "cancel," in streams I came up with (fairly artificially) the idea that abort is "forceful" and will cause the resulting stream to error, as seen by any other consumers of it, whereas cancel signals "loss of interest" and will just act as if the stream is closed. In promises I think the semantics might be rejecting with a new `Cancellation` exception for "abort" vs. becoming forever-pending (and cleaning up underlying resources) for "cancel." Amusingly, both of these semantics are being tried in promise libraries these days.

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/625#issuecomment-74558034