always true | false check with TypePredicate

[Kingwl]

Search Terms

TypePredicate

Suggestion

call a function with TypePredicate with an obviously true or obviously false argument is always useless,
and that maybe get a incorrect type guard, could we check this case or another limit set?

Use Cases

Examples

interface Node { 
  //...
}
interface Identity  extends Node { 
  //...
}
interface WTFIdentity extends Identity { 
  //...
}

function isIdentity(node: Node) node is Identity {
    // ...
}

function isWTFIdentity(node: Node) node is WTFIdentity {
  // ...
}

declare const a: Identity;
declare const b: Identity | StringLiteral;
declare const c: StringLiteral;

isIdentity(a); // obviously true
isIdentity(b); // normal behavior
isIdentity(c); // obviously false
isWTFIdentity(a);  // normal behavior
isWTFIdentity(b);  // normal behavior
isWTFIdentity(c);  // obviously false

Checklist

My suggestion meets these guidelines:

• [] This wouldn't be a breaking change in existing TypeScript / JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. new expression-level syntax)

[mhegazy]

I am not sure about the "obviously false" cases.. Types in TS are open, and we also have intrersection type, so do not see why you can not have a value that is both StringLiteral and WTFIdentity.

For the always true ones, i think this falls in the same category as the unneeded type assertion in tslint: https://palantir.github.io/tslint/rules/no-unnecessary-type-assertion/

[mhegazy]

I would recommend adding this check to https://palantir.github.io/tslint/rules/no-unnecessary-type-assertion/ or another similar rule.

[ajafff]

I'm already planning to implement such a lint rule: fimbullinter/wotan#127
Unfortunately this is not as easy as it seems.
The always true case might be pretty straightforward, but the always false case requires checking all nested properties of the resulting type for impossible intersections.

Currently this is not really possible to implement, because there is no way to create an IntersectionType using an API.
I remember that this was part of a PR that exposed type relationship APIs (or at least it was discussed there). Unfortunately it didn't get merged. @mhegazy is there anything blocking the addition of 2 new methods on TypeChecker: createIntersectionType and createUnionType? Maybe missing type factories? Should I open a new issue to discuss that further?

[typescript-bot]

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