Incorrect type narrowing with async/await

[RareScrap]

🔎 Search Terms

"type narrowing", "async", "await", "promise"

🕗 Version & Regression Information

• This changed between versions ______ and _______
• This changed in commit or PR _______
• This is the behavior in every version I tried, and I reviewed the FAQ for entries about all relevant to async/await and Promises
• I was unable to test this on prior versions because _______

⏯ Playground Link

https://www.typescriptlang.org/play/?target=99&jsx=0#code/IYZwngdgxgBAZgV2gFwJYHsI2QUxMgCgEoAuGABQCd0BbVEHAHgDd1UATAPhgG8AoGIJgAbHMnipK+AEp50w5jnZVa9HABUwABxxkARAEY9MAD4w9AJmNmk7HHFQQlMALwxb9x0oFComfDAA2lrUdAwGKmE4AMpiyKLssiAIwsgANDAhqgwWkWqxyPFKSSnIALquMMAA7sCo4nkMAHTAwsIFRewEgT5CQo04TZRyCjgEetG0OANGRE3IABY4EAT1rtz8fVtCDlLISfKKyqFqmjowAPwXboZ6vdtCw8gIlFj1930AvkRpH-0nzWGIEOYwmUwGVjmi2Wq3ELg2f22uxkIyOAzOOEu13MVkRWyeLzeyDx33uZSIfHuAHoqTB1EtMtQAEaiGgwejYBbAcR+GhaVCiSgwZLDTmY5DaTEczDCMDuCB2BxOdgwaoLVBQBbskCq6gQADm9z8EGBoiawnQ+oIAANkftUUp0ZKXAASHh2g6jY7ZDSSz7Wil9Y2mwYWq1ZKIRAExOIJEqpQO+fzyUOWggRtS5aMdON4UoUz6U3D4YhAA

💻 Code

async function test(): Promise<void> {
    let firstResolvedPromiseType: "1" | "2" | undefined = undefined
    const [promise1PromiseSettledResult, promise2PromiseSettledResult] = await Promise.allSettled([
        Promise.resolve("SomePromise1").then(it => {
            firstResolvedPromiseType ??= "1"
            return it
        }),
        Promise.resolve("SomePromise2").then(it => {
            firstResolvedPromiseType ??= "2"
            return it
        })
    ])

    // The problem is that compiler sure the type is only undefined which is wrong
    console.log(`firstResolvedPromiseType=${firstResolvedPromiseType}`)
    console.log(promise1PromiseSettledResult)
    console.log(promise2PromiseSettledResult)
}

test()

🙁 Actual behavior

Compiler is absolutely sure that the only possible value of firstResolvedPromiseType is undefined which is wrong:

🙂 Expected behavior

Compiler correctly determine the type of firstResolvedPromiseType as "1" | "2" | undefined

Additional information about the issue

No response

[MartinJohns]

Another duplicate of #9998.

[ritschwumm]

the problem here is twofold:

• tsc chooses to ignore the type annotation on firstResolvedPromiseType in favor of the inferred type of the assignment's RHS, which is undefined (something i personally find very unintuitive)
• tsc does not look into callbacks for possible mutations of a variable like firstResolvedPromiseType (which hard to get right, if even possible)

for each of these problems, people have opened a lot of duplicate issues in the past.

the only workaround i know about is using a separate function to construct the initial value of your variable which stops tsc from narrowing the type.

i usually do something like this:

const identity = <T>(it:T):T => it;
let firstResolvedPromiseType = identity<"1" | "2" | undefined>(undefined);

but this would work, too:

let firstResolvedPromiseType = (():"1" | "2" | undefined => undefined)();

[MartinJohns]

Much simpler option to prevent the narrowing-upon-assignment:

let firstResolvedPromiseType: "1" | "2" | undefined = undefined as typeof firstResolvedPromiseType

But this has the slight gotcha that something like "5" wouldn't report an error, because type asserting different strings is allowed.
And this could be avoided by adding satisfies, which makes this very verbose (but type-safe):

let firstResolvedPromiseType: "1" | "2" | undefined = undefined satisfies typeof firstResolvedPromiseType as typeof firstResolvedPromiseType

---

• tsc chooses to ignore the type annotation on firstResolvedPromiseType in favor of the inferred type of the assignment's RHS, which is undefined (something i personally find very unintuitive)

And other people would find the opposite confusing, because suddenly this code would no longer work:

let val: number | undefined = 12
val.toExponential()

Think of it this way: the type annotation tells the compiler what types are allowed to be assigned to this variable.

• tsc does not look into callbacks for possible mutations of a variable like firstResolvedPromiseType (which hard to get right, if even possible)

Besides being hard to get right, it's also a massive performance issue.

[jcalz]

#61789 #56235. I find assignment narrowing intuitive but there are times when it isn't desired. It would be nice if there were a dedicated satisfiesas/satisfias/ sassafras operator so you could do a non-narrowing assignment without repetition (or having to define your own function for it).