Failure to refine tuple union return type when destructuring

[jaredh159]

TypeScript Version: 3.5.1

Search Terms:
destructure tuple destructuring

Code

function tuple(): [null, string] | [string, null] {
    if (Math.random() < 0.5) {
        return [null, 'a string'];
    }
    return ['a string', null];
}

const arr = tuple();

if (arr[0] === null) {
    arr[1].toUpperCase(); // <-- 👍 Works! TS knows arr[1] is a string
}

const [a, b] = tuple();

if (a === null) {
    b.toUpperCase(); // <-- 🚨 Error! TS doesn't know b is a string
}

Expected behavior:
TS can refine the destructured variables based on the function union return type.

Actual behavior:
Error.

It makes sense that when I do

const [a, b] = tuple();

That at that point, a and b need to both have an inferred type of null | string.

But when inside the conditional check if (a === null) I was expecting type refinement. Maybe that's an impossibility, but TS has gotten so smart I was genuinely surprised it wasn't able to refer that b was a string at that point.

Playground Link:
https://www.typescriptlang.org/play/#code/GYVwdgxgLglg9mABFEAHANgUwBQEoBciA2mCOugDSIDOUATjGAOYC6iAPsbQ81aeWwDeAKERjEMYImwBZAIZQAFgDo6csABM4AWzyIAPIgAMygKy5EI8dcR1MKOkhJlKiAORya9RkzcsA3KLiAL5BYnYOTh5ePL58LgHCocIQCLSIcnR0iAC8yGhYeIHCktKZdERGbDk1iPzoFlbi5UQAjCzKUHAAqqiomHQAwnLUOLiByalg6URyVABG1fkYY8Wl2J41efWNYYjznT19A8OjRUlAA

Related Issues:
maybe #28311 ?

[fatcerberus]

Duplicate of #12184, but just for full context:

Basically the type system doesn't track any dependencies between different variables, destructured or otherwise. When you write a type guard such as if (a === null), the compiler can only narrow the variable(s) directly involved in the guard expression, in this case a. It doesn't have any way of knowing internally what that narrowing implies for b.

It's for the same reason that the following doesn't work:

const isNull = arr[0] === null;
if (isNull) {
    b.toUpperCase(); // <-- error here
}

As far as I understand, tracking this kind of thing would represent a lot of added complexity in the control-flow analyzer, so TS doesn't even try to do it.

[jaredh159]

Ok, thanks @fatcerberus for the explanation and the link. Makes sense.