TypeScript: Inconsistent inference behaviour on union types

The behaviour of ternary operator inference (and similarly if-else & switch-case) seems to be inconsistent between types

TypeScript Version: Tested on 3.7+ up to nightly

Search Terms: union, union inference, inconsistent inference

Code

class ErrorA extends Error {
  readonly _tag = "ErrorA"
}

class ErrorB extends Error {
  readonly _tag = "ErrorB"
}

interface X<E> {
  e: () => E
}

const A = { e: () => "a" as const }
const B = { e: () => "b" as const }

const C = { e: () => new ErrorA() }
const D = { e: () => new ErrorB() }

const E = { e: () => ({a: "0"}) }
const F = { e: () => ({b: "1"}) }

declare const someBoolean: boolean
declare function fn<E>(x: X<E>): E

Expected behavior:

const OK = fn(someBoolean ? A : B) // inferred as "a" | "b"
const NO = fn(someBoolean ? C : D) // inferred as ErrorA | ErrorB
const NO_2 = fn(someBoolean ? E : F) // inferred as {a:string} | {b:string}

Actual behavior:

const OK = fn(someBoolean ? A : B) // inferred as "a" | "b"
const NO = fn(someBoolean ? C : D) // doesn't compile
const NO_2 = fn(someBoolean ? E : F) // doesn't compile

Playground Link: https://www.typescriptlang.org/play?#code/MYGwhgzhAECiBO8D28CC0CmAPALhgdgCYwLLzQDeAUNNPBmIUviAJ7QD6OYA5tALzQARKRSohVAL5UqoSCUQoAQplwFicReWq16jZm07c+gkVqUTpVAJb488AGZhgGaAA0APLAB8lGpgAuaAAKAEoBX1gpGWBmCBxodEEKQJDw-l8hMCFoSGhY-HjoaQKilWTUsIjhACMcvNKEq0boAGEBSkr033wMAHdNMlQqkriEgBEOlIwgqozoXoHReCURmLG4Ka7q4IowIKEABiFJcNHChIAxLZm0nYoag4BGE7OZQgw5enyNiCQAWwwSiQSBADHwQRqILBYHwVA+X1cDgArvhgDhrMxoA58F5vMEsEFPD5QkEorINgB5ADSHRxwT+gOBoPB0AA-IloEElKEKRdoAA5Sl0-AMgFA6GsjntILjXktIUcABMIrFTMlsPZmyCl15QA

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 8
Comments: 18 (8 by maintainers)

Most upvoted comments

@RyanCavanaugh For that particular example I don’t think you can soundly infer a union since find might mutate the array. But I get your point when the function is defined as

function find<T>(haystack: readonly T[], needle: T): number {

ahejlsberg on Sep 21, 2020

We have a few ad hoc rules in place, such as always unioning literal types from the same domain, but otherwise, when no inference candidate is a supertype of all other inference candidates, we simply pick the first (for some meaning of first) candidate and leave it to the user to resolve the resulting errors though casts or explicit type arguments.

Ideally we would separately track inferences for mutable vs. read-only locations and produce union types whenever it is sound. For example:

declare function foo1<T>(a: T, b: T): T;

foo1('abc', 'def');
foo1('abc', 42);  // Could soundly infer 'abc' | 42

function foo2<T>(a: T[], b: T[]) {
    a[0] = b[0];
}

foo2(['abc' as const], [42 as const]);  // No sound inference here

function foo3<T>(a: readonly T[], b: readonly T[]) {
    a[0] = b[0];  // Error
}

foo3(['abc' as const], [42 as const]);  // Could soundly infer 'abc' | 42

Some have made the argument that an error is preferable to a union type, even when a union type would be sound, because T is intended to represent a single type. For example, the error on foo1 is better than a union type because the a and b parameters are supposed to be of the same type. I’m not sure I buy that argument when a union type could soundly be inferred.

ahejlsberg on Sep 21, 2020

@RyanCavanaugh understood, thanks for the examples, going in your direction of being explicit on the behaviour wanted by the programmer a way to get the best of both worlds might be to add some sort of variance annotations on the generics, thinking of something of the sort:

declare function fn<A+, B->(a: X<A, B>, X<A, B>): X<A, B>

where if + is specified the types would mix with a union and if - is specified types would mix with intersection (+/- is the notation in Scala)

mikearnaldi on Sep 21, 2020

Well ideally when we can infer something sound it seems to be a better approach to infer the best candidate instead of forcing an error that will lead to manual casting of the types to a common ancestor

mikearnaldi on Sep 21, 2020