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

the guard against cancellation is simply a non-cancel-able Promise because I think `.cancel()` should probably not be invokable by default. Same as `then` is the method key to figure out a Promise from a generic object, `cancel` is in CancelablePromise-land the method key to know if a Promise is cancelable.

Since cancelable promises resolve their state regardless, these can be wrapped without problems through regular Promises, whenever we reach them before others and we don't want to provide `.cancel()` method outside our little world when we pass the Promise around.

In plain Vanilla JS, and using your rejection approach, this is technically what I mean:
```js
// simulating my second proposal manually
var cancel, cancelable = new Promise(function (res, rej) {
  // le async resolution
  var interval = setTimeout(res, 1000, 'OK');
  cancel = function (why) {
    clearTimeout(interval);
    rej(why);
  };
});
// making it cancel-able out there ... 
cancelable.cancel = cancel;


// now this would be possible ...
// cancelable.cancel('no-more');


// but now I intercept this object
// and I'd like to not make it cancel-able anymore
var nope = new Promise(function (res, rej) {
  cancelable.then(res, rej);
});

// passing back `nope` instead
// so that whoever tries the following
nope.cancel();
// will fail ... but
// instead of that ...
// this would have worked
cancelable.cancel('because');
```

Now you have a `cancelable` Promise inside a regular `nope` Promise that cannot be canceled.

This is option number 2 in my opinion, but I agree it simplifies the whole circus.

It's also probably more pragmatic since there's no `canceled` virtual state to resolve, and developers can react as soon as they can understand what's the cough error about.

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