Design Meeting Notes, 10/6/2017

[DanielRosenwasser]

Contextual Types from Overloads

• When we start to contextualy type function expressions, and there are multiple "unlikE" candidates, we just give up - you end up with any for your parameter types.
  • Comes up in situations like React's refs field.

    type Foo = ({ (x: string): void } | string)
             & ({ (x: number): void } | string)

    • Same as Ref<string>["ref'] & Ref["ref']`.
  • We want to do better here.
• Catches errors, introduces better intellisense
• This makes sense for intersections - maybe not as much for unions?
• For intersections of function types, this is better - more accurate to model the sorts of things you're trying to satisfy.
• Any time a contextual type is requested, does this synthesize a completely new signature?
  • Yes
    • Well, we've had an assumption that these are cheap to make.
      • Maybe that's not a good assumption. :)
  • We already do this for contextual types of properties and other members; signatures are the only places where we don't do that.
• Contextual types usually keep your types capable while allowing you to do the things you wanted to do.
  • Maybe this should only occur under noImplicitAny.
• Unioning the parameters are a "slam dunk" for intersection types.
• What about just intersections and not unions?
  • Doesn't solve original use-case.
• Some not convinced this is the best way to solve the React case.
• In general, let's think about this more. noImplicitAny case seems convincing.

Excess Properties on Discriminated Unions

#12745

• Code seemed relatively simple!
• Check-time is reduced, makes Wesley's fully discriminated union branch faster!
• It's merged!

Default import synthesis

#16093

• Helps interop with Babel code
• Helps users migrate to Node interop scheme
• Conclusion: yeah, let's do it.