Assignability rule for conditional types needs to require check types and distributivity to be identical

TypeScript Version: master (e4718564e5b2c1f2e7bbef27fc480fd8172dfdc0)

Search Terms: assignable assignability conditional type check type checkType distributive distributivity identical unsound

Code

type MyElement<A> = [A] extends [[infer E]] ? E : never;
function oops<A, B extends A>(arg: MyElement<A>): MyElement<B> { 
    return arg;  // compiles OK, expected compile error
}
oops<[number | string], [string]>(42).slice();  // runtime error

type MyAcceptor<A> = [A] extends [[infer E]] ? (arg: E) => void : never;
function oops2<A, B extends A>(arg: MyAcceptor<B>): MyAcceptor<A> { 
    return arg;  // compiles OK, expected compile error
}
oops2<[number | string], [string]>((arg) => arg.slice())(42);  // runtime error

type Dist<T> = T extends number ? number : string; 
type Aux<A extends { a: unknown }> = A["a"] extends number ? number : string;
type Nondist<T> = Aux<{a: T}>;
function oops3<T>(arg: Dist<T>): Nondist<T> {
    return arg;  // compiles OK, expected compile error
}
oops3<number | string>(42).slice();  // runtime error

Expected behavior: Compile errors as marked.

Actual behavior: Compiles OK, runtime errors as marked.

Playground Link: link

Related Issues: None found

[jack-williams]

@jcalz @mattmccutchen Related to that issue: #27470. (I’ll leave the discussing of this issue at that as I don’t want to go off topic).

[mattmccutchen]

@jack-williams Assuming the conditional types are non-distributive (sigh), you are close. We may want to account for nontransitivity of assignability. For example, consider:

function foo<A, B extends A>(arg: A extends number ? {} : never):
    B extends number ? {} : never {
    return arg;
}
let n: never = foo<any, string>({});

I suspect the concept we would need may be similar to the “definitely assignable” relation that is used to evaluate conditional types. Or we could just say that anyone who writes the above code deserves what they get.