include proposed `Promise.prototype.finally`

basically just:

/**
  `finally` will be invoked regardless of the promise's fate just as native
  try/catch/finally behaves
  Synchronous example:

  findAuthor() {
    if (Math.random() > 0.5) {
      throw new Error();
    }
    return new Author();
  }
  try {
    return findAuthor(); // succeed or fail
  } catch(error) {
    return findOtherAuther();
  } finally {
    // always runs
    // doesn't affect the return value
  }

  Asynchronous example:

  findAuthor().catch(function(reason){
    return findOtherAuther();
  }).finally(function(){
    // author was either found, or not
  });

  @method finally
  @param {Function} callback
  @return {Promise}
*/
  finally(callback) {
    let promise = this;
    let constructor = promise.constructor;

    return promise.then(value => constructor.resolve(callback()).then(() => value),
                  reason => constructor.resolve(callback()).then(() => { throw reason; }));
  }

Questions:

• should 4.0.0’s es6-promise/auto polyfill the whole promise, or just finally if finally is not present?
• should we wait a-bit longer or is the risk sufficiently low to just :shipit: cc @domenic

[ljharb]

@shirakaba this isn’t a future spec feature; finally is stage 4 - it’s already in the language (in ES2018).

In other words, if the core TS library lacks a definition for finally, that’s a bug in TS.

[shirakaba]

Okay, it looks like it may potentially even be a WebStorm IDE issue – Typescript has a lib called lib.esnext.promise.d.ts – importable via --lib esnext.promise, but WebStorm’s language service does not have this library file, so I suspect I’d be unable to use it without issue.

WebStorm’s language service has most of the TypeScript core libs, but also lacks lib.es2018.d.ts. Their lib.esnext.full.d.ts, like TypeScript’s official one, does not include finally(), either. I’ll have to look into it.