Design Meeting Notes, 3/16/2022

[DanielRosenwasser]

Deleting the {} and unconstrained type parameter assignability rule

#33570

(previous design notes at #37388)

• We used to use {} as the top type. This was before null and undefined.
• Then we added unknown as a true top type.
• We made type parameters' implicit upper bound unknown.
• But we kept a loophole where generic type parameters were assignable to {} to avoid breakages.
• Should this be gated on strictNullChecks?
  • Generic bounds not enforced on generic argument #32330 possibly has some motivation that you want this regardless.
    • Still seems arguably related to strictNullChecks.
• Try making the apparent type of unknown be unknown #47517 seems related.
  • This PR improved a lot of error messages, but broke a bunch of code.
• "Non-strictNullChecks is an insane pointless garbage system"
• Conclusion: at least do this for strictNullChecks.

Error Message on "...could be instantiated with an arbitrary type which could be unrelated to..."

#47889 (review)

#29049

• We created this message after getting tons of issues around constraints.
• This is extremely obnoxious when you're 30 error elaborations deep.
  • "By the way, string isn't necessarily assignable to T, thought you might like to know."
  • "Yes, thank you but I have other things to worry about."
• Honestly, Stack Overflow helps teach people here.
• Would feel okay getting rid of this for the unconstrained version.
• Conclusion
  • Would be okay with simplifying error messages here.
  • Open to seeing what it looks like to remove the "unconstrained type parameter check."
  • Open to doing this only for simple types.