Design Meeting Notes, 1/19/2022

[DanielRosenwasser]

Expressions with Type Arguments

• There's several requests for people to be able to say "I want to be able to talk about a specific instantiation of a function or constructor". For example, if you wanted an alias of Map that could only work for strings to Errors.

• Also when you write code like foo<T>(yadda), this is already valid code in JavaScript.

  • It's relatively meaningless, but there's already auto-generated code with a semantic difference.

• In retrospect could have imagined separating out type argument instantiation with invocation.

• Already have something like this in extends clauses - ExpressionWithTypeArguments.

• So what if you could write:

  const ErrorMap = Map<string, Error>;
  
  new ErrorMap();
  
  // or directly at the use-site
  
  new (Map<string, Error>)(); // does not work today

• Similarly

  function makeBox<T>(x: T): Box<T> {
      // ...
  }
  
  const makeAppleBox = makeBox<Apple>;
  makeAppleBox(new Apple());
  
  // or directly at the use-site
  
  (makeBox<Apple>)(new Apple()); // does not work today

• Idea: runs through existing signatures that take the appropriate number of type arguments, and drops any others.

• Distributes across unions, and must apply to at least one signature in one type in the union. If no signatures got resolved, then it's an error.

• Have to parenthesize? Means that this is at odds with optional chaining.

  • This is contentious - seems like if one motivation is avoiding conflict with JS, it's iffy.

• typeof?

  • typeof Map<A, B> vs (typeof Map)<A, B> - slightly different!
  • Can you express this both of these?
    • No. Type references need to be qualified names.
  • Is it confusing to have both of these constructs?
    • Maybe not, but may want both.
    • A bit confusing that you can't control between call and construct signatures.

• Conclusion:

  • Return to this.

Properties on unknown when --strictNullChecks false

#47494

try {}
catch ({ message }) {

}

• Shouldn't be able to get message off of unknown.
• But you get a bad error message outside of strictNullChecks but with useUnknownInCatchVariables
• "If you got into TypeScript after unknown, this all makes no sense."
• {} used to be the top type, moved towards unknown.
• In order to not break everything, we kept the apparent type as {} outside of strictNullChecks mode.
• Conclusion:
  • Maybe take that out, make unknown always assignable to {} outside of strictNullChecks.