Repository navigation
Type guards should be flowed #10734
Description
type A = number | string
function isNumber(_): _ is number { return typeof _ === 'number' }
const as: A[] = [1, 2, '3']
// (1) - OK: bs is number[]
let bs = as.filter(isNumber)
// (2) - Not OK - cs is still A[], but should be number[]
let cs = as.filter(_ => isNumber(_))
// (3) - Not OK - ds is still A[], but should be string[]
let ds = as.filter(_ => !isNumber(_))
Activity
mhegazy commentedon Sep 7, 2016
The request here is to infer user defined type guards from return expression of functions. i.e.:
benschulz commentedon Dec 14, 2017
I wish this issue got more attention because a bit of inference could go a long way.
I implemented a form of type predicate inference in 982c35f to get a feeling for the complexity. It goes beyond just propagating type predicates as outlined here and infers them as requested in #18572 and #19468. It's only a sketch and does not handle some common cases nor some of the edge cases I saw in other places that do type narrowing. That notwithstanding, I think the (implementation) complexity of an inference scheme for simple arrow types might be acceptable. However, I obviously lack the broader understanding necessary to properly assess this.
I want to emphasize how valuable an inference scheme like this could be. Manually specified predicates are not verified and thus error prone. The most common use case, as can be seen in #18572 and #19468, are
filterfunctions. Anybody who uses rxjs in combination with redux or some other library that encourages flux standard actions likely hasObservables of such actions and filters them bytype. redux-observable has a dedicated function for this, which gives type safety at the cost of redundancy (both the type argument and thetypemust be specified.Once again, I wish this issue would get more attention. =)
mhegazy commentedon May 2, 2018
Seems like a duplicate of #16069
RyanCavanaugh commentedon Jun 24, 2021
Tracking at #16069