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

Experiment short-circuiting of union distribution #47511

Closed
5 tasks done
RyanCavanaugh opened this issue Jan 19, 2022 · 2 comments
Closed
5 tasks done

Experiment short-circuiting of union distribution #47511

RyanCavanaugh opened this issue Jan 19, 2022 · 2 comments
Labels
Experience Enhancement Noncontroversial enhancements Experimentation Needed Someone needs to try this out to see what happens Suggestion An idea for TypeScript
Milestone

Comments

@RyanCavanaugh
Copy link
Member

RyanCavanaugh commented Jan 19, 2022

Suggestion

πŸ” Search Terms

union distribute short-circuit performance

βœ… Viability 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, new syntax sugar for JS, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

@amcasey and I were discussing #47481 and he had an interesting observation. Consider this program:

type HugeUnion1 = "a" | "b" | "c" | "d" | ... [10,000 more];
type HugeUnion2 = "q" | "r" | "s" | "t" | ... [10,000 more];

type Square<T, U> = T extends U ? true : false;

type M = Square<T, U>;

Naively, when evaluating M, we need to check if every member of HugeUnion1 is present in HugeUnion2. However, let's say we saw this (in the sorted form):

type HugeUnion1 = "a" | "q" | ... [10,000 more];
type HugeUnion2 = "a" | ... [10,000 more which do not include 'q'];

After evaluating "a", we have a true. After evaluating "q", we have a false. We can skip the rest of the list since no subsequent result will change the answer (because T does not appear in the conditional result)

Moreover, if instead of false we had never, we could immediately stop after seeing true, since true | never is just true

@RyanCavanaugh RyanCavanaugh added Suggestion An idea for TypeScript Experience Enhancement Noncontroversial enhancements Experimentation Needed Someone needs to try this out to see what happens labels Jan 19, 2022
@RyanCavanaugh RyanCavanaugh added this to the Backlog milestone Jan 19, 2022
@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Jan 20, 2022

Seems like this would use similar rules as @ahejlsberg's #46429, right? You can avoid distribution and just map to a set of possibilities for A extends B ? C : D when

  • The check-type (A) appears in neither branch and
  • The extends type (B) has no infer positions

With the possibilities never, C, D, C | D, and possibly any (?)

@jakebailey
Copy link
Member

With #53192 merged, I think that this one is effectively "done"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Experience Enhancement Noncontroversial enhancements Experimentation Needed Someone needs to try this out to see what happens Suggestion An idea for TypeScript
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants