Repository navigation
Allow parenthesis in type guards #32130
Description
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 codePredicate 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.
Activity
MartinJohns commentedon Jun 27, 2019
Duplicate of #10421, #31512, #31879, #17760.
RyanCavanaugh commentedon Jun 27, 2019
Duplicate is correct - allowing this syntactically would not be sufficient to enable the behavior you're looking for
Haringat commentedon Jun 27, 2019
Ryan Cavanaugh (@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 commentedon Jun 27, 2019
You posted this code:
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 commentedon Jun 27, 2019
Haringat You do use a new kind of flow analysis. Today a simple function call such as
assertString(it);can't impact the type ofit. With your proposal it could impact the type ofit.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,switchstatemenets, 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 thatassertStringhas 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 commentedon Jun 27, 2019
Titian Cernicova-Dragomir (@dragomirtitian) ah I think I am starting to get it now. Thanks for the explanation.
typescript-bot commentedon Jun 29, 2019
This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.