Promises of different types should not be compatible

TypeScript Version: nightly

Code

const x: Promise<string> = Promise.resolve("");
const y: Promise<number> = x;

Expected behavior:
Compiler error on line 2.

Actual behavior:
No error.

[yortus]

In the definition of Promise<T> in lib.d.ts, if you comment out the nullary overload of then, then you get the expected behaviour. I do not understand why, I was just trying to reproduce the behaviour with a simpler case and discovered that.

// in lib.d.ts:
interface Promise<T> {
   /*...*/
    then<TResult1, TResult2>(onfulfilled: (value: T) => TResult1 | PromiseLike<TResult1>, onrejected: (reason: any) => TResult2 | PromiseLike<TResult2>): Promise<TResult1 | TResult2>;
   /*...*/
    // then(): Promise<T>;     <===== comment this one out
   /*...*/
}


// in code.ts:
const x: Promise<string> = Promise.resolve("");
const y: Promise<number> = x; // ERROR: 'Promise<string> is not assignable to 'Promise<number>'

[jeffreymorlan]

I came up with those overloads in #9193, but under closer examination they are actually subtly wrong. TypeScript's model of function arguments assumes that extra args beyond those declared in the signature are ignored - and therefore, a function signature is assignable to a function signature with more parameters. Although you can pass 0 or 1 arguments to Promise.then, it does not ignore its first and second arguments; we do not want this rule applying to it.

I think the right way to declare Promise.then is to make all the overloads 2-arg, with optional parameters of type null (technically, any non-function can be used to get the passthrough behavior, but passing anything other than null/undefined is almost certainly a mistake)

interface Promise<T> {
    then(onfulfilled?: null, onrejected?: null): Promise<T>;
    then<TResult>(onfulfilled: (value: T) => TResult | PromiseLike<TResult>, onrejected?: null): Promise<TResult>;
    // other overloads here
}

EDIT: This only fixes the problem when --strictNullChecks is on. Changing null to never doesn't help, but changing it to string does. Not sure why...

[OliverJAsh]

Is this still an issue?

const commits: Promise<number> = Promise.resolve('foo') // no error!

[mhegazy]

thanks @OliverJAsh. this should be fixed after @rbuckton's latest change to the Promise definitions.

You can still do this:

const x: Promise<number | string> = Promise.resolve("")
const y: Promise<number> = p

Here's how that causes errors:

function f(f: () => Promise<{ x: number }>) {}
f(async () => !true ? { x: 1 } : "")

(not sure why the error happens for { x: number } but not for number.)

Meaning, an async function can return a value of the wrong type if it has multiple returns (and thus returns a union type, which is a subtype of the correct type.)

There's a fix:

interface Promise<T> { __promiseBrand: T }

This enforces the Promise type as if it already had the value, which is probably how people want to view it -- if T isn't assignable to U, Promise<T> shouldn't be assignable to Promise<U>. And it makes sense, because internally you could think of promises as having a _resolvedValue: T private member, which eventually gets written to.