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

Design Meeting Notes, 4/14/2023 #54225

Closed
DanielRosenwasser opened this issue May 12, 2023 · 0 comments
Closed

Design Meeting Notes, 4/14/2023 #54225

DanielRosenwasser opened this issue May 12, 2023 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Unioning Signatures Across Array Methods

#44373

#53489

interface Fizz {
    id: number;
    fizz: string;
}

interface Buzz {
    id: number;
    buzz: string;
}

([] as Fizz[] | Buzz[]).filter(item ==> item.id < 5); // not allowed
  • Long-standing issues with typing unions of array methods.
  • We have special logic to combine single signatures across unions.
    • Only single signatures.
    • filter, find, reduce have multiple signatures.
      • At least in ES6.
    • Issues around setting contextual types during inference and not being able to backtrack.
  • Idea: arrays are special - maybe special-case these?
  • Could this be extended to more generally apply to instantiations of the same generic type?
    • Arrays have to be handled special-case in the general case due to hard-coded variance assumption.
    • Have to do variance calculation of each type parameter in the signature - could do it, don't do it today.
      • Non-trivial amount of work.
    • Also - downside of this is that the output type would be awkward, possibly questionable.
  • Users hit this very often - would like to get this fixed.
  • Long-term do we want the general solutions?
    • Possibly - the two solutions (doing the same thing for every type, resolving across unions) are possibly expensive.
  • Let's not let perfect be the enemy of good for now.

Slow Type-Checking with Large Enum

#53761

  • Have a huge enum type - 1500 elements.
  • Have something like Record<A, B>[A] where A is this enum.
  • Original logic to construct this was to create the candidate set for each K in A as Record<A, B>[K] - then reduce the overall array.
  • New logic - cache the immediate last type, see if the new type is identical. If so, don't add.
  • Great optimization, dropped to 50% of the time, but still long check time.
  • Also noticed that the original case was a Partial<...> of the original.
    • If calling getUnionType with a pair of types (two types), create a cache key more quickly.
  • We do spend a lot of time flattening out unions of unions.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label May 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

2 participants