You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
The text was updated successfully, but these errors were encountered:
Always Report
useDefineForClassFields
-Related Errors#59623
useDefineForClassFields
(or if implicitly in a newer target).useDefineForClassFields
in 6.0.useDefineForClassFields
+ignoreDeprecations
until 6.5?Perform subtype reduction on call expression types if type argument arity fails
#60036
Array<T> | ReadonlyArray<T>
.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.reduce<...>(...)
, that'll fail.Array<T> | ReadonlyArray<T>
? Why not just writeReadonlyArray<T>
?Array.prototype.reduce
is a pretty special case andArray<T> | ReadonlyArray<T>
being reduced appropriately?The text was updated successfully, but these errors were encountered: