Design Meeting Notes, 9/15/2021

[DanielRosenwasser]

Type Display Comparison

https://gist.github.com/orta/f80db73c6e8211211e3d224a5ab47624
#45786

• Improving error messages by thinking about them strucutrally.

• Interesting approach: two column approach.

• Everything goes through the same diagnostic output pipeline.

• Big win would be to introduce newlines.

• Pitch: not something we'd want to do by default, but maybe something we could put into tsc --init.

• Lots of stuff becomes possible once you give this a thought.

• Examples are conveniently not long lines.

• Also, wrapping?

  • Have to consider line length.
  • We can do that.

• Only should do stuff like this if the objects are big enough.

• Feels like there's a lot of stuff we could have benefitted from where the diagnostic system would be "lazy", and supported formatting.

• Aren't we already agreed on the

  Type
  { x: Yadda }
  
  is not assignable to type
  { y: Badda }
  

  • Yes, that already feels like a general improvement, but this isn't that.

• These might look good in theory, but not be in practice.

• Inspecting the width of the console?

  • Not always desirable
  • Copy/paste is useful for that.
  • Columns break vertical space.

• When we explore constraints of types, we can explore many many levels deep

  • Have LOTs of info, which is accurate but it's bad.
  • We have a way of reporting all the overloads.
  • But anecdotally, users don't want to see ALL the overloads, they want to pick the most-likely one.
    • Something like "betterness" in overload resolution in other languages that is not incorporated into our overload resolution itself.

• We want to reduce the pyramids by showing the structures.

  • Print back a structure.
  • Maybe print back the pieces as we descend into the type.

• Find the vertical presentation confusing.

• Generally having types that are diffed, maybe on their own line.

  • That on its own helps with people being able to "naturally" diff.

• Conclusion:

  • Continue prototyping.
  • Will create a follow-up issue.

Type Display for Unresolved Symbols

#45893
#38836

• Have a prototype where we just create aliases to any.
• Preserves type display.
• But as soon as you try to use something of this "fake any" type, it collapses unions to any.
• Does this have to be an any? Could be its own type.
• Supports any number of type parameters.
  • Any number? Or only the number of type arguments given to the first?
  • Should work.
• Declaration emit?
  • Need yet another flag for typeToString probably.
• We don't distinguish anys that you get from different contexts.
  • unresolved?
• Maybe quick info could show something at the bottom that says "some stuff was not resolved".
• New display part could be special-cased.
• Does VS Code actually respect display parts?