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 we have a generic object type (e.g. interface Foo<T, U> {}, we've made the assumption that T and U are covariant with respect to Foo.
We based this on the fact that when comparing parameter types in functions, we do a bivariant comparison.
Given this, relating type arguments covariantly should provide true positives, and we can fall back to a structural check when the check doesn't succeed.
However, now we are trying to introduce rules where parameters are (usually) strictly compared in a contravariant manner.
This means we can no longer make that assumption.
So what we do is we introduce two internal types, one which is a subtype of the other, and create two instantiations with each for each type parameter. We then do a structural comparison to see what the variance is based on relatability using each direction.
But there are places where this doesn't work out all that well.
Strict Function Types
When we have a generic object type (e.g.
interface Foo<T, U> {}
, we've made the assumption thatT
andU
are covariant with respect toFoo
.However, now we are trying to introduce rules where parameters are (usually) strictly compared in a contravariant manner.
But there are places where this doesn't work out all that well.
readonly
.Current working proposal is that under
strictFunctionTypes
, the only types that get stricter are ones declared using() => T
)new () => T
)However that means that
() => T
will no longer be equivalent to{ (): T }
under these rules.How plausible is it to turn this on by default?
--strict
.We will definitely have to go over DefinitelyTyped to make sure this works okay.
For our declaration emitter, we need to make sure we emit the correct types.
Different diagnostic severities for
noUnusedLocals
/noUnusedParameters
#15953
info
diagnostic?warnAsError
on by default?The text was updated successfully, but these errors were encountered: