docs: finalized wiki integrity maintenance (v3.0 standard) - pruned 1400+ stubs and fixed 11k+ ghost links
This commit is contained in:
@@ -1,4 +1,4 @@
|
||||
[[Variance (Covariance, Contravariance, Invariance)]]
|
||||
[[Variance (Covariance, Contravariance, Invariance)|Variance (Covariance, Contravariance, Invariance)]]
|
||||
📌 Brief Summary
|
||||
Variance describes how the subtyping relationship between complex types (such as functions or generics) relates to the subtyping relationship of their component types. In TypeScript's type system, understanding variance is critical for designing safe interfaces, as it determines whether a subtype can be substituted for a supertype without violating type safety.
|
||||
|
||||
@@ -21,8 +21,8 @@ In the context of TypeScript interface design, variance defines the rules for "s
|
||||
When designing interfaces, developers must decide the variance of generic parameters. Using `in` (contravariant) and `out` (covariant) annotations (though primarily a feature of languages like C# or Scala, the logic applies to how TypeScript infers compatibility) allows for more flexible and reusable API designs.
|
||||
|
||||
🔗 Knowledge Connections
|
||||
* Related Topics: [[Liskov Substitution Principle]], [[Function Type Compatibility]]
|
||||
* Projects/Contexts: [[TypeScript Structural Type System]]
|
||||
* Related Topics: [[Liskov-Substitution-Principle|Liskov Substitution Principle]], Function Type Compatibility
|
||||
* Projects/Contexts: TypeScript Structural Type System
|
||||
* Contradictions/Notes: Note that TypeScript's type system is "structural," meaning variance is determined by the shape of the object rather than explicit declarations, which can sometimes lead to unexpected compatibility in complex nested generics.
|
||||
|
||||
Last updated: 2026-04-17
|
||||
Reference in New Issue
Block a user