infer type of tuple from single elements

[phra]

hi,

while working on await-to-ts i discovered that i cannot publish the to function with the return type of Promise<[Error, null] | [null, T]> but only with Promise<[Error, T]> because it cannot infer correctly the tuple type on partial informations on elements. you can find a live example of this in this branch

TypeScript Version: 2.3.1

Code
playground link

function f(flag: boolean): [number] | [string] {
	if (flag) {
		return [0]
	}

	return ['0']
}

const res = f(true)[0]
if (typeof res === 'number') {
	res // is a number, it works correctly
} else {
	res // is a string, it works correctly
}

const res2 = f(true)
if (typeof res2[0] === 'number') {
	const tmp1 = res[0] // is string | number, it should be number
} else {
	res // is a string, it works correctly
}


function g(flag: boolean): [number, string] | [string, number] {
	if (flag) {
		return [0, '0']
	}

	return ['0', 0]
}

const res1 = g(true)
if (typeof res1[0] === 'number') {
	const tmp1 = res1[0] // is string | number, it should be number
	const tmp2 = res1[1] // is string | number, it should be string
} else {
	const tmp1 = res1[0] // is string | number, it shuold be string
	const tmp2 = res1[1] // is string | number, it should be number
}

Expected behavior:
based on partial informations, the type system should be able to infer tuple type correctly.
Actual behavior:
the type system fails to infer tuple types with partial informations about elements.

[jurajkocan]

suggestion workaround with objects instead tuples: 15482

[kitsonk]

Yeah, I still think fixing this or #15482. TypeScript could narrow these types. Certainly related though.

[phra]

i think that it should be a killing feature because in my case i can use the type system to signal to the user that is trying to access the resolved value of the promise without checking the error before, because if you don't check the err variable the resolved value will have a null | T type, after checking the error the type will be correctly T.
@jurajkocan i was thinking about that, maybe i can give it a try and see, but the tuple syntax is for sure more elegant in this case.

[phra]

no plan to see this FR approved soon?

[mhegazy]

Duplicate of #12849

[mhegazy]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.