Type narrowing not working for unions of tuples with object literals

[squidfunk]

It's not possible to narrow unions of tuples with object literals

TypeScript Version: 3.4.5, 3.5.0-rc

Search Terms: tuple narrow object literals

Code:

Narrowing tuples with primitive types works as expected:

type X = ["a", "c"] | ["b", "b"]

function bar(x: X) {
  if (x[0] === "b") {
    return x[1] === "c" // correctly narrows to "c", shows "condition always false"
  }
}

However, when the tuple contains object literals, narrowing doesn't work at all:

interface A { data: "a" }
interface B { data: "b" }
interface C { data: "c" }

type Y = [A, C] | [B, B]

function foo(y: Y) {
  if (y[0].data === "b") {
    return y[1].data === "c" // incorrectly narrows to "c" | "b"
  }
}

Expected behavior:

The object literal within the tuple is correctly narrowed down to type B

Actual behavior:

The object literal is not narrowed, leaving it at type C | B.

Playground Link: Link

Related Issues:
#26323
#24120
#10530

[midzdotdev]

Hi guys, not sure if this helps but here's another example which I believe to be the same issue:

type FieldArray = string[]
type FieldSet = Record<string, any>

type FieldParams =
  | [ FieldArray, FieldSet ]
  | [ FieldArray ]
  | [ FieldSet ]

function convertFieldParams (fields: FieldParams): Field[] {
  const normalised = typeof fields[1] === 'undefined'
    ? fields[0] instanceof Array
      ? [ fields[0], {} ]
      : [ [], fields[0] ]
    : fields

  // ...
}

I would expect the normalised variable to have a type of [ FieldArray, FieldSet ] due to the type checking, although it's showing in my editor as Record<string, any>[].

I found a workaround by doing this:

const normalised: [ FieldArray, FieldSet ] = 
    fields.length === 1
      ? fields[0] instanceof Array
        ? [ fields[0], {} ]
        : [ [], fields[0] ]
      : fields

[squidfunk]

Any update? Fixing this issue would make tuples much more powerful :-)

[GeeWee]

Probably same as #12849
I've narrowed the issue down a little bit, as to where it breaks down:
playground link

type DataFetchingResponse2 = [number, 'loaded'] | [null, 'error' | 'loading'];


function test2(): DataFetchingResponse2 {
	return [null, 'error'];
}

function testTypeNarrowing() {
	const res2 = test2();

    // This works fine and correctly narrows res2[0] down to number
	if (res2[1] == 'loaded') {
		const data2 = res2[0];
	}

    
    // This does not, but casts it as a number|null
    const status = res2[1]
	if (status == 'loaded') {
		const data2 = res2[0];
	}

    // This also does not, as it thinks dataFromDestructuring is number|null inside the type narrowing
    const [dataFromDestructuring, statusFromDestructuring] = res2
	if (statusFromDestructuring == 'loaded') {
		console.log(dataFromDestructuring)
	}
}

So narrowing directly on the tuple type works fine, but when destructuring or assigning to an intermediate variable, it does not narrow correctly.

[squidfunk]

@GeeWee: I think that those are effectively two separate bugs, as the issue describes type narrowing without destructuring on tuples with primitive (working) and non-primitive (not working) values.

[GeeWee]

I think you're probably right actually.

[DanielRosenwasser]

Looks like this is probably a bug in isMatchingReference.

[Kingwl]

I'd like to try this if no one started work

[sandersn]

Sounds good, I wasn't planning to start on it until after the beta starts.

[sandersn]

This is actually not specific to tuples. Control-flow narrowing doesn't work with any nested properties:

interface A { data: "a" }
interface B { data: "b" }
interface C { data: "c" }

type Y = { a:A, b:C } | { a:B, b:B }

function foo(y: Y) {
  if (y.a.data === "b") {
    return y.b.data === "c"
  }
}

It probably could be done but would require us to either (1) re-think handling of unions of object types or (2) how to relate entity-named discriminants that share a prefix.

[jtbandes]

Possibly related: #48378

[squidfunk]

3 years old, still not fixed. Is this issue dead? It was first scheduled for 3.7 and then repeatedly rescheduled until it ended in the backlog. Fixing this would help in several use cases and greatly improve expressivity. I have several parts in my code base where I need to fall back to very generic types that are not helpful at all what could be a union of tuples.