bug(lib): Explicitly stating wrong return type of `Promise.then` without arguments results in no error

[iluha168]

🔎 Search Terms

• silenced Promise resolution type mismatch
• Promise generic explicit no error
• no error when Promise type is specified explicitly
• generic inside optional argument

🕗 Version & Regression Information

TS v3.3.3 correctly detects the error, which is the earliest Playground version. All other Playground versions silence the error.

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=6.0.0-dev.20260312#code/MYewdgzgLgBFCm0BcMAKAnEBbAlheAPNOjmAOYB8MAvGprvgHTqIgA2AbvABQCMAlIygALeGG78A3EA

💻 Code

const test: Promise<string> = Promise.resolve(1).then();

🙁 Actual behavior

No TypeScript errors.

🙂 Expected behavior

I expected a similar error to what TS v3.3.3 yields:

Type Promise<number> is not assignable to type Promise<string>. Type number is not assignable to type string.

Additional information about the issue

No response

[jcalz]

So maybe then() should be typed more like

interface Promise<T> {
    then<T1 = T, T2 = never>(
        onfulfilled?: ((value: T) => T1 | PromiseLike<T1>) | undefined | null,
        onrejected?: ((reason: any) => T2 | PromiseLike<T2>) | undefined | null
    ): Promise<NoInfer<T1 | T2>>;
}

with NoInfer<>?

[iluha168]

The return value hint usually is useful, and adding NoInfer is a huge breaking change:

const specificPromiseType: Promise<1> = Promise.resolve().then(() => 1)
   // ^? Promise<1>
const notSpecificPromiseType          = Promise.resolve().then(() => 1)
   // ^? Promise<number>

Moreover, generics can be set manually:

const test = Promise.resolve(5).then<"string">()
	// ^? Promise<NoInfer<string>>

Perhaps we could utilize overloads and split this definition into two - one with function onfulfilled, and the other - with non-function onfulfilled? (No need to split onrejected, for the same reason Promise.catch does not have this issue - its default type is never, any other generic would be less specific.)

interface PromiseLike<T> {
    then<TResult1 = T, TResult2 = never>(
        onfulfilled: (value: T) => TResult1 | PromiseLike<TResult1>,
        onrejected?: ((reason: any) => TResult2 | PromiseLike<TResult2>) | undefined | null
    ): PromiseLike<TResult1 | TResult2>;
    then<EasierMigrationGenericIGuess = T, TResult2 = never>(
        onfulfilled?: undefined | null,
        onrejected?: ((reason: any) => TResult2 | PromiseLike<TResult2>) | undefined | null
    ): PromiseLike<T | TResult2>;
}
// And the same for Promise<T> except the return type is also a Promise

The sample code now results in this error [Playground]:

const test: Promise<string> = Promise.resolve(1).then();
/*
Type 'Promise<string | number>' is not assignable to type 'Promise<string>'.
  Type 'string | number' is not assignable to type 'string'.
    Type 'number' is not assignable to type 'string'
*/

The error description is not perfect, but it does result in expected behavior if onrejected is split too. [Playground]

[Andarist]

Another instance of when .then's typing affects some scenario negatively can be seen here: #62071

[paigefletcher1282-code]

Yes #62071 this hasn't yet to be reproduced

…

On Thu, Mar 12, 2026, 10:15 PM Mateusz Burzyński ***@***.***> wrote: *Andarist* left a comment (microsoft/TypeScript#63244) <#63244 (comment)> Another instance of when .then's typing affects some scenario negatively can be seen here: #62071 <#62071> — Reply to this email directly, view it on GitHub <#63244 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B7BB4JXG634YR24O6ZAFLQL4QMZIFAVCNFSM6AAAAACWPMLHP2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANJQGU2DSMRRGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>