Design Meeting Notes, 9/24/2024

[DanielRosenwasser]

Always Report useDefineForClassFields-Related Errors

https://github.com/microsoft/TypeScript/pull/59623

• When a dev writes a parameter property and a class field depends on the parameter property, we error under useDefineForClassFields (or if implicitly in a newer target).
• We want to issue the error regardless of the target.
• We like the idea but it could cause a lot of issues. No code fix today which makes it harder.
• We will just deprecate useDefineForClassFields in 6.0.
• Should clarify what the plan is for this (@RyanCavanaugh) - is the idea that we just flip the emit and errors over in 6.0 and let people set useDefineForClassFields+ignoreDeprecations until 6.5?

Perform subtype reduction on call expression types if type argument arity fails

https://github.com/microsoft/TypeScript/pull/60036

• Let's imagine Array<T> | ReadonlyArray<T>.
• They both have the same reduce method overloads. Two of them are considered identical, but one generic signature which is the same isn't surfaced because we don't consider common methods as identical.
  • So if you write reduce<...>(...), that'll fail.
• The idea here is that if you write a type argument and it doesn't match any signature's arity, the checker will subtype-reduce the expression type and try again.
• Seems very special-casey.
• Why are you writing Array<T> | ReadonlyArray<T>? Why not just write ReadonlyArray<T>?
• One weirdness here is the fact that you need to provide type arguments for this to kick in. This is a little bit ad-hoc and makes it hard to reason about. As a user, you wouldn't necessarily expect type arguments to trigger any special behavior.
  • Array.prototype.reduce is a pretty special case and
• Maybe there should be a special rule about Array<T> | ReadonlyArray<T> being reduced appropriately?
• We have other special-cases around arrays, why is this one bad?
  • Those were not ideal, but they were motivated by common pain-points around operating on arrays. The issue this addresses doesn't have a lot of feedback other than the current report.
• For now we've decided not to pursue this change.