3.5 regression: return type forced more restrictive than needed

[bluescreen303]

TypeScript Version: 3.5.0-dev.20190508

Search Terms: restrictive return type

Code

class Box<A> {
    constructor(public val: A) {}
}

interface ContainerFor<A> {
    array: Array<A>;
    box: Box<A>;
}

function single<T extends keyof ContainerFor<number>>(t: T, x: number): ContainerFor<number>[T] {
    switch (t) {
        case "array":
            return new Array<number>(x);
        case "box":
            return new Box<number>(x);
    }
    return new Box<number>(0); // this should not be needed
}

function test() {
    let t1 = single("array", 42);
    let t2 = single("box", 42);
    //let t3 = single("boo", 42);
}

Expected behavior:
This code worked with 3.4, but had an unsoundness bug in that single was allowed to return the wrong type (swap array and box). It was clear that switching over t did not increase knowledge about the expected output type and I was forced to have a fallback return which is of course unreachable. But the code itself worked.

The test function also shows things work as expected. The types for t1 and t2 are inferred correctly and asking for an unknown thing ("boo") is reported as an error.

I would expect this to still work in 3.5, perhaps fixing one of the issues I'm having in the internals of single.

Actual behavior:
Typescript 3.5 no longer accepts this code. returning new Array or new Box are flagged as wrong return types. The newly expected return type is now mandated to be the intersection type: number[] & Box<number>, which is too restrictive as the correct output type can be statically determined from T in the input. The fact that test correctly infers the output type is proof of this.

[bluescreen303]

Adding @DanielRosenwasser to this, as he seemed to like this example :)

[weswigham]

The break is intentional - we made indexed accesses no longer have an overly-lax constraint when the target of a comparison (we need to guarantee you cover every possible type for every possible input type, after all).
We'd need to infer a T extends "array" ? number[] : T extends "box" ? Box<number> : never for the return type and successfully exhaustively reconcile it with ContainerFor<number>[T] (whose constraint is essentially the aforementioned conditional) to typecheck this safely.

[bluescreen303]

It's funny how from the outside of the function (so from test) the correct return type is expected while on the inside the same conclusion cannot be reached when t is known.

[weswigham]

Yeah, tracking each return expression's dependence on t is hard.

[AnyhowStep]

Unrelated but, instead of,

return new Box<number>(0); // this should not be needed

Why not throw an Error?

This way, if your code is used by a JS developer (or a TS developer playing with any) and they pass an invalid value, they get an Error instead of having this silently pass and returning a possibly unintended value.

[bluescreen303]

Good point.
But this code is mainly a minimal case to show the point, not real code.

[bluescreen303]

@weswigham You mention the break is intentional. I agree that the 3.4 behaviour (allowing the function to return anything) is problematic, so breaking "invalid" programs sounds reasonable.
But I would expect that it should never be the intention to break perfectly valid programs that were accepted by the type checker before.