Design Meeting Notes, 2/21/2020

[DanielRosenwasser]

Update on Reducing Impossible Intersections

#28663

• Better errors because a bunch of empty intersections
• A couple of failures on DefinitelyTyped
  • 2 are legit: trying to access properties or extend from an empty intersection
  • 1 thing that failed was Ramda
    • Uses ts-toolbelt
      • Depends on keyof (A & B) being the same as (keyof A) | (keyof B), which is still true except for when the intersection is empty.
        • If A & B more-often reduces to never (the proposed change), then keyof (A & B) should become keyof never.
      • Fixable by sending a PR to ts-toolbelt - but that doesn't necessarily mean that other things won't break.
• How can a user diagnose the keyof (A & B) being the same as keyof never (being the same as never)?
  • We special-cased to print back never for A & B.
  • We need to ensure that A & B doesn't leak - it has to be an implementation detail.
    • Are the updates for that finite and known.
• Conclusion: probably good to go, @ahejlsberg will need to ensure we have consistent behavior during type argument inference.

Permitting Deeply Nested Conditionals

#28663

• Two "competing" solutions
  • By flattening: Flatten immediately nested conditional types in the false position #36583
  • By adjusting the instantiation count: Allow deeply nested immediately resolving conditionals without any syntactic requirements #36584
• For each of these, we just keep diving into each conditional and increment the type instantiation counter, which eventually triggers the type limiter.
• A lot of people's mental model is that each layer of the conditional belongs to one over-arching construct.
  • So the idea of Flatten immediately nested conditional types in the false position #36583 is to just treat the whole structure of conditionals as one big ol' type to operate on at once.
  • Really helps all nested conditionals in the false branches.
  • We've talked about type switches, but that's just the same as a bunch of nested conditional types.
• The limitation is that this the first approach is limited to syntactically nested conditional types.
  • Lots of cases where there are conditionals with type aliases to each other.
  • So there's a broader problem.
  • Also, would the original change mean we would never cache the deeper conditional?
    • No, you only need to cache at the top level.
    • But that's not true for the type aliases case.
      • But we only "optimize" here for the syntactic case - otherwise we will cache.
• Can we combine these approaches? e.g. optimize for syntactic cases and then still avoid triggering the depth increment cases.
  • Seems like yes.
• Also, this code looks like people are trying to discriminate on types - would there be some optimizations?
• These both help pathological cases - does it impact the simple case?
• Conclusion: @weswigham and @ahejlsberg to work together and explore combining both approaches.