Design Meeting Notes, 12/1/2017

[DanielRosenwasser]

Partial generic type arguments

#10571

• Partial inference for generic type arguments
  • Today we either infer all or none
• Gets a little bit confusing for defaults
  • Today, if you have a parameter list like in f<T, U, V = never>(x: T, y: U, z: V): void, a type argument list like in f<string, boolean>("", true, 100) will infer never for V and cause an error.
    • Argument of type '100' is not assignable to parameter of type 'never'.
• This would technically be a breaking change.
  • But might be hard to actually encounter.
  • Though, type parameter defaults with any might be a case.
• So idea: always do inference, and maybe do an optimization when all type parameters are "fixed".
• Should you be able to mix positional/named?
  • Either
    • Only positional & only named
    • Positional followed by named

#19205

• Comes up with Vue's <Data, Computed, Methods, PropNames>
  • Want to be able to add Props, but it comes last.
  • Even if it didn't come last, people want to be able to specify these.
    • By the time you have 5 type arguments, you really won't be able to reason these.
• Do we want to do this even if associated types might be another option?
  • Seems like we could still do this and tackle associated types later.
• Syntax
  • Technically an invalid left-hand side, should be fine.

Conclusions

• Partial inference
  • Do it, infer in place of default arguments, and continue to use the default when no inferences are available.
• Named type parameters
  • Positional followed by named

Extracting returned/constructed types

#6606
#20350

• Undergoing overload resolution is problematic.
  • Implementation is super complex and you run into several circularity problems.
• Could just give the union, but what abut type parameters?
• What about the "zero-order" problem? In other words, no overloads.
  • This is one of the most common cases.
• Does this solve things cases like promisify?
  • No, you need variadic kinds.
• Would match types take care of this?
  • They wouldn't be able to decompose overloads.
• What about a zero-order typeof?
  • What does that even mean?
• How's this different from const x: typeof x?
  • We can short-circuit more easily based on the symbol thanks to the restricted forms.

[UselessPickles]

Just want to say that I'm very excited about partial inference of generic type arguments :)

I just ran into this limitation a few minutes ago, and it's nice to see that there is already active planning for it.