somePromise.catch or .then(null, rejectFn) should preserve type of original promise but doesn't

[wardbell]

The fundamental point is that the catch of a promise should NOT change the type of that promise unless it returns something different. Returning something different is relatively rare because the activation of the catch should be rare.

Because catch is sugar over then(null, rejectFn), that form has the same issue.

Example 1: foo returns Promise<Hero>

    foo(){
        return Promise.resolve(new Hero('foo'));
    }

Example 2: foo returns a Promise<{}> ! This is AWFUL

    foo(){
        return Promise.resolve(new Hero('foo'))
                  // Pick any of these to see the problem
          .catch()
          .catch(e => {})
          .then(null, e => {})
    }

Example 3: foo returns a Promise<{}> ! This is AWFUL TOO

    foo(){
        return Promise.resolve(new Hero('foo'))
                  // Pick either of these to see the problem
          .catch(e => Promise.reject(e))
          .then(null, e => Promise.reject(e))
    }

Example 4: foo returns a Promise<Hero> ... but this is baroque

    foo(){
        return Promise.resolve(new Hero('foo'))
          .then(_ => _, e => Promise.reject(e));
    }

The problem is in the typings file I think. I contend that that catch or then(null, rejectFn) should be typed to return a Promise<Hero>.

[jocull]

+1. This is worse because for lack of better type information it becomes Promise<any>. Sneakily destroying your other typing information along the way. (making them all any)

[mhegazy]

// CC: @rbuckton

[RyanCavanaugh]

Ping @rbuckton ?

[rbuckton]

While the results of the above scenario have changed since the introduction of strictNullChecks and other recent improvements to the type checker, there are still some issues with the resulting types in the above scenarios.

I'm investigating improvements to the Promise type declarations to see what could help.