Design Meeting Notes, 4/26/2019

[RyanCavanaugh]

• Suggestion: treat in operator as type guard which asserts property existence #21732 in operator as type guard
  • Contrast with typeof foo.a === 'string' (which is not allowed)
  • What would happen then?
    • Generate an intersection with { a: unknown } ?
    • Same as the posted workaround
  • Danger for unknown here becase "a" in x throws for x undefined / null / number / etc
  • We should restrict this, if we do it, to object to avoid unexpected exceptions
  • We could do it; should we?
  • We already use in as a type guard when property absence is a psuedo-discriminant, which introduces some inconsistency if we do both
  • Some discussion of how the in narrowing works
  • Proposal is to only introduce this when the property is not present in any constituent of the right operand
  • Many people pretend their types are sealed, which is fine if you're consistent about it
  • Worth a try, accepting PRs
• Support higher order inferences for constructor functions #31116 Higher-order inference for constructors
  • Does what it says on the tin; same as we did for functions
  • Takes a constructor and produces a function that calls the constructor, effectively
  • Still subject to limitations around return type syntax
  • What about mixins, as usual?
    • With new work, this can be better-supported
    • Same as before, we'd be unable to correctly prevent name collisions
    • This pattern doesn't support static members
      • Trade-off because now it's not a higher-order operation
      • Why not just add another parameter with the same type? And treating that as a desugaring of the proposed version?
        • Now there's no place to put the type parameter
      • Problem: Need to ensure that static members can't see the synthetic type parameters
  • Cut for time
• Fix relations for instantiations of same generic signature #31029 / Generic type alias produces erroneously compatible types #31006 DT memory problems with Ember and styled-components
  • Behavior as described is due to constraint erasure during type comparison
    • This is a correct shortcut as long as the constraint doesn't reference an outer type parameter
    • Except for all the anys introduced causing problems
  • What if we didn't erase them?
    • Found a couple bugs
    • Sooooooo much more work to do!
    • Ember's extensive use of keyof this means they're very reliant on bivariance
      • Now we generate a large number of unions when there are local type parameters
    • styled-components v3 eats 4 GB of RAM and dies
      • v3 needs another workaround?
      • What do we do about bug fixes that expose combinatorial explosions?
      • Some possible perf fixes around variance measuring, but the general problem is... general
      • Add a workaround to v3, fix ember, deliver this fix, and start looking harder at DT's performance characteristics