Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type guards should be flowed #10734

Closed
bcherny opened this issue Sep 6, 2016 · 4 comments · Fixed by #57465
Closed

Type guards should be flowed #10734

bcherny opened this issue Sep 6, 2016 · 4 comments · Fixed by #57465
Labels
Duplicate An existing issue was already created

Comments

@bcherny
Copy link

bcherny commented Sep 6, 2016

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(_))

Similar issues: #7657, #5101, #5951

@mhegazy
Copy link
Contributor

mhegazy commented Sep 7, 2016

The request here is to infer user defined type guards from return expression of functions. i.e.:

function isNumber(a): a is number {
....
}

function myIsNumber(a) {
    return isNumber(a);  // should infer `a is number`
}

function isString(a: number | string) {
    return !isNumber(a);  // should infer `a is string`
}

@benschulz
Copy link

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 filter functions. Anybody who uses rxjs in combination with redux or some other library that encourages flux standard actions likely has Observables of such actions and filters them by type. redux-observable has a dedicated function for this, which gives type safety at the cost of redundancy (both the type argument and the type must be specified.

Once again, I wish this issue would get more attention. =)

@mhegazy
Copy link
Contributor

mhegazy commented May 2, 2018

Seems like a duplicate of #16069

@RyanCavanaugh
Copy link
Member

Tracking at #16069

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants