Suggestion Backlog Slog, 8/23/2021

[andrewbranch]

8/23/21

• Allow type annotation on catch clause variable #20024
  • Extra relevant given new --strict mode flag
  • Pretty upvoted
  • What about catch (err as Error)?
    • Will this conflict with the ES spec?
    • Wouldn't we rather people test the type of err?
    • Would be nice if ES had pattern matching in catch clauses
    • No need to rush toward an imperfect solution here
  • Action: remove from backlog review list
• Show unused public properties and methods #29293
  • Related to demand for an internal modifier
    • Internal to whom?
  • If you're developing a library, that's different from writing an app
    • It would have to be project-wide
    • How to deal with project references? You have to open every consuming project. Super expensive and complicated.
    • There are other issues where it would be nice to know package vs. app, like do you want declaration emit because you're going to ship definitions or just as an artifact of --build?
  • Pretty upvoted
  • Subclassing makes it complicated too, and structural assignability makes it nearly impossible to try to guess
  • Wouldn't want this every time you request diagnostics (with suggestions)
  • Does CodeLens cover this? Kind of a hack on VS Code's side, but still might be your best bet.
  • Action: remove from backlog review list, bring up at editor sync, but don't think we can do this anytime soon
• Overload gets lost in mapped type with conditional type #29732
  • We take the last signature and that's what we infer from
  • Modest upvotes
  • What else could we do?
    • Try to distribute all the signatures, infer each individually, and squash them back together into an intersection / overload list
    • Or just infer a union for the arguments and union for the return type? Not exactly incorrect, just looser than desired.
      • Worth pursuing? It would be special-cased a bit. It sort of makes sense if the inferred type parameters capture the entire parameter list and return type, like this example, but what if you have something like (x: infer T, y: infer U) => infer R or (x: string, y: number, z: infer T) => infer R? These cases are less clear, and we don't currently do any kind of pattern matching to match up the concrete parameters with a matching overload—we always just take the last overload.
  • Action: come back to it later to see if we're hit with a stroke of brilliance

[andrewbranch]

@DanielRosenwasser I'll leave it to you if you want to add #29293 to the editor sync agenda—there are no other outstanding action items from this so I’m closing.