When is guards for incompatible types are assigned to each other, an error occurs (breaks Array filter)

[conartist6]

TypeScript Version: 3.3.0-dev.20190119

Search Terms:
filter, type guard, mutually exclusive guard

Code

class MyArray<T> {
    constructor(arr: Array<T>) { };
    filter<S extends T>(callbackfn: (value: T, index: number, array: ReadonlyArray<T>) => value is S, thisArg?: any): MyArray<S> { return (null as any); };
    // Do not include fallback case! This is how MyArray differs from Array's filter type.
    // filter(callbackfn: (value: T, index: number, array: ReadonlyArray<T>) => any, thisArg?: any): T[];
}

declare function isBoolean(a: any): a is boolean;

declare const numArr: Array<number>;
const test1: Array<boolean> = numArr.filter(isBoolean);
// Here I'd expect Array<never>
// The actual result is Array<number>
// This is because the type guarded case is falling through completely

declare const myNumArray: MyArray<number>;
const test2: Array<boolean> = myNumArray.filter(isBoolean);
// When there is no such case, the error becomes clear

Expected behavior
When is guards for incompatible types are assigned to each other, the result should be never.

Actual behavior
When is guards for incompatible types are assigned to each other, an error occurs.

[jack-williams]

I can see how the behaviour is difficult to debug; generic overload inference is not a simple thing! I'm afraid I don't have insight on whether this should be fixed, but something that might help is if you write your type guards like this:

declare function isBoolean<T>(a: T): a is T & boolean;

This way you get the never[] type in the first case, as you expected.

[conartist6]

Interesting. That will indeed help me for the moment. As far as I can tell the conservative thing to do would be to write all type guards that way, which says to me that this would be a fixable bug.

[conartist6]

So when i use that technique to define my type guards, the type after refinement becomes... inconsistent.

For example it seems to matter at that point whether I do an is refinement against one type or more than one type, e.g. foo is T & Bar vs. foo is T & (Bar | Baz)).

Also when the refinement is against only one type, it seems that the result is likely not to be never. In the case of the exmaple above it comes out as Bar & T which, though Bar and T may not overlap, is not never.

[conartist6]

I'm going to work on putting together a PR to fix this, unless anyone informs me that I should not. It would of course be a breaking change to existing types, since existing incorrect types have presumably grown up around the existing incorrect behavior.

[jack-williams]

What is the use case for applying a type guard to something that is known to be a disjoint type?

^{Btw, I have nothing to do with TypeScript development so please don't take anything I say as a suggestion against submitting a PR!}

[conartist6]

The use case is the built in type of Array.prototype.filter which will produce results that are 100% verifiably wrong when this underlying condition happens.

As to why the condition would happen, I don't think it matters at all. To say the least, the main point of Typescript is to give correct and helpful output when the program is incorrect. More often than not a never type resulting from filter will be an indication that the program is incorrect, which Typescript should capture.

The other problem is that never doesn't work very well at all when used as Array<never>. It behaves completely backwards from what you would hope.

In theory it it should be possible to add any type of item to an array of never, resulting in an array of that type of item. It should never be possible to attempt to get an item from an array of never, because there will never be such an item.

In practice though what happens is that you can pull any value out of the Array (!) but no value can be inserted into it : (

[RyanCavanaugh]

const test1: Array<boolean> = numArr.filter(isBoolean);
// Here I'd expect Array<never>
// The actual result is Array<number>

Ideally it would be never[], but this doesn't seem "wrong" to me - the array will be empty, and an empty array is a number array from a covariant perspective.

When is guards for incompatible types are assigned to each other, the result should be never

There's not really an assignment taking place here per se. A possibility would be to add an overload to filter that accepted only type guards of non-T types, and returned never[], but I don't see how in practice that would be a useful thing to have.

I'm not seeing any options that would "fix" this scenario without introducing other problems.

[conartist6]

@RyanCavanaugh
When you say there's not really an assignment taking place I don't catch your meaning. There are two type predicates. Some code is generating the diagnostic Type predicate 'a is boolean' is not assignable to 'value is number'. The union of two disjoint sets is empty, which in the case of a predicate means that the guarded code will never have a condition in which it may execute, which is the definition given to the never type. Given that the never type is its own first class construct, I don't see how you can suggest that it doesn't matter if it is generated when it should be.

What would change is that the following would be a new type error:

numArr.filter(isBoolean)[1] = 1;

That this expression constitutes an error seems like a regression, as I know was a programmer that the code is safe and what type should result. However I do not think that the fact that one bit of incorrect behavior is covering up for another is reason not to modify either. Two wrongs don't make a right; two bugs don't make a feature.

[RyanCavanaugh]

What is the concrete behavior change you want to see?

[conartist6]

When an a is number is assigned to b is boolean I would like for the result to be never.

[RyanCavanaugh]

When an a is number is assigned to b is boolean I would like for the result to be never.

Assignability produces a yes/no answer, not a type

[conartist6]

Ah. Design limitation indeed then.

[fatcerberus]

In theory it it should be possible to add any type of item to an array of never, resulting in an array of that type of item.

So you would think at first, but type theory says otherwise - never is the bottom type: you can’t assign anything to it (because there can never be anything meaningful there, see how that works? 😉), but everything is assignable from it. That last part is maybe counterintuitive, but it makes sense when you consider that it’s the exact opposite of unknown, the top type.