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 predicates and narrowing Arrays #50359

Closed
5 tasks done
mbartelsm opened this issue Aug 18, 2022 · 3 comments
Closed
5 tasks done

Type predicates and narrowing Arrays #50359

mbartelsm opened this issue Aug 18, 2022 · 3 comments
Labels
Duplicate An existing issue was already created

Comments

@mbartelsm
Copy link

mbartelsm commented Aug 18, 2022

Suggestion

πŸ” Search Terms

type narrowing array

βœ… Viability Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
    • It's a matter of accurately inferring types, it would only make code less verbose by requiring fewer type assertions.
  • This wouldn't change the runtime behavior of existing JavaScript code
    • Purely a typing issue
  • This could be implemented without emitting different JS based on the types of the expressions
    • This only makes it easier to appease the typechecker
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
    • It's a compile-time change
  • This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Currently, it is not possible to narrow down the type of a union of arrays based on the types of their contents, even if the arrays of the union are disjunct. I suggest updating the typechecker, if possible, to allow for this.

πŸ“ƒ Motivating Example

If we try to do it the naive way, we get the following scenario:

function fun1(array: number[] | string[]) {
    if (array.length > 0 && typeof array[0] === "number") {
        array // Actual type:  number[] | string[]
              // Desired type: number[]
    }
}

function fun2(array: [number, ...number[]] | [string, ...string[]]) {
    if (typeof array[0] === "number") {
        array // Actual type:  [number, ...number[]] | [string, ...string[]]
              // Desired type: [number, ...number[]]
    }
}

Instead, the programmer is forced to write a type assertion on top of verifying the type of the array

function fun1(array: number[] | string[]) {
    if (array.length > 0 && typeof array[0] === "number") {
        array as number[]
    }
}

function fun2(array: [number, ...number[]] | [string, ...string[]]) {
    if (typeof array[0] === "number") {
        array as [number, ...number[]]
    }
}

This is not ideal, as it makes for needlessly verbose code. There's also no simple way to implement a type predicate to do this generically over any array of any type.

The ideal scenario would be for the first example to infer the desired types.

πŸ’» Use Cases

This makes for cleaner code and a more streamlined and intuitive user experience. The current approach makes for clunky and bloated code when dealing with arrays, as the only way to properly type things is with type assertions.

@MartinJohns
Copy link
Contributor

This sounds like a duplicate of #45301 to me, which was marked as a duplicate of #42384.

@mbartelsm
Copy link
Author

mbartelsm commented Aug 18, 2022

Ahhh, I was looking for suggestions, not bug reports, so I missed #45301.

I did notice #42384, but is it be the same situation? I'm not exactly sure how the type-checker works w.r.t. arrays and objects.

Should I delete this?

@RyanCavanaugh RyanCavanaugh added the Duplicate An existing issue was already created label Aug 18, 2022
@typescript-bot
Copy link
Collaborator

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

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

No branches or pull requests

4 participants