Allow parenthesis in type guards

[Haringat]

Search Terms

type guard parenthesis

Suggestion

I would like to be able to put the asserting part of a type guard function in parenthesis to be able to further work with it.

Use Cases

I have two use cases in mind right now: strong-typed assertions and predicate inversion. However, there may be more that I currently don't think of.

Examples

Strong typed assertions

This would enable code like this:

function assertString(it: unknown): (it is string) extends true ? void : never {
    if (typeof it !== string) {
        throw new Error("not string")
    }
}

This would make the following code possible:

function doSomethingWithStrings(it: unknown) {
    assertString(it);
    return it.startsWith("foo") // it must be a string now
}

It would also allow better detection of dead code/bugs:

function doSomething(it: number) {
    assertString(it);
    // unreachable code

Predicate inversion

function not<T>(predicate: (it: unknown) => it is T): (it: unknown) =>  (it is T) extends true ? false : true {
    return (it: unknown): (it is T) extends true ? false : true => !predicate(it);
}

Using a few more functional predicates we could do something like this:

const isNotNullOrUndefined = not(or(isUndefined, isNull));

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. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• [*] This feature would agree with the rest of TypeScript's Design Goals.

[MartinJohns]

Duplicate of #10421, #31512, #31879, #17760.

[RyanCavanaugh]

Duplicate is correct - allowing this syntactically would not be sufficient to enable the behavior you're looking for

[Haringat]

@RyanCavanaugh Ok, from what I read in the issues this is mostly about control flow analysis performance.
However, in the above example I did not use new kind of control flow that is not already in typescript (basically the above examples are a combination of conditional types and type predicates) so I do not understand why each one individually is accepted in the language but the combination is not. Edit: Or rather, why the combination would lead to an unacceptable type checking performance drop.

[MartinJohns]

However, in the above example I did not use new kind of control flow that is not already in typescript

You posted this code:

function doSomethingWithStrings(it: unknown) {
    assertString(it);
    return it.startsWith("foo") // it must be a string now
}

This would not work with the way the control flow works today, even if your proposed syntax is allowed. Functions can not change the type of a variable within the current scope. Allowing that would require the changes in the control flow analysis.

[dragomirtitian]

@Haringat You do use a new kind of flow analysis. Today a simple function call such as assertString(it); can't impact the type of it. With your proposal it could impact the type of it.

Typescript builds a graph of nodes that can impact the type of variables. This graph includes nodes of constructs that can impact the type of a variable (such as if, switch statemenets, assignments etc). With this change ALL calls would have to be included in this graph (the graph is constructed when type information about the function is not yet available, so there is no way to know that assertString has an impact on CF while other functions don't).

This is why such a change would have a big performance impact, it would grow the CFA graph by a lot.

[Haringat]

@dragomirtitian ah I think I am starting to get it now. Thanks for the explanation.

[typescript-bot]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.