Open
Description
Always Report useDefineForClassFields
-Related Errors
- 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
- 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.
- So if you write
- 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 writeReadonlyArray<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.