Contrasting covariant and contravariant positions within Typescript

Question

Contrasting covariant and contravariant positions within Typescript

I'm currently diving into the examples provided in the Typescript advanced types handbook to broaden my understanding.

According to the explanation:

The next example showcases how having multiple potential values for the same type variable in co-variant positions leads to an inferred union type:

type Foo<T> = T extends { a: infer U, b: infer U } ? U : never;
type T10 = Foo<{ a: string, b: string }>;  // string
type T11 = Foo<{ a: string, b: number }>;  // string | number

Similarly, when there are multiple possible values for the same type variable in contra-variant positions, it results in an inferred intersection type:

type Bar<T> = T extends { a: (x: infer U) => void, b: (x: infer U) => void } ? U : never;
type T20 = Bar<{ a: (x: string) => void, b: (x: string) => void }>;  // string
type T21 = Bar<{ a: (x: string) => void, b: (x: number) => void }>;  // string & number

This raises the question: why are the object properties in the first example referred to as "co-variant positions" while the function arguments in the second example are called "contra-variant positions"?

Additionally, the second example appears to result in never and I am unsure if any additional configuration might be needed to make it work properly.

typescript covariance

Answer 1

Answer №1

Your keen observation about one of the examples resulting in never is accurate, and you are not overlooking any compiler settings. In more recent TypeScript versions, intersections of primitive types lead to a resolution of never. If you switch back to an older version, you will still observe string & number. The newer version showcases contravariant position behavior when using object types:

type Bar<T> = T extends { a: (x: infer U) => void, b: (x: infer U) => void } ? U : never;
type T21 = Bar<{ a: (x: { h: string }) => void, b: (x: { g: number }) => void }>;  // {h: string; } & { g: number;}

Playground Link

The reason why function parameters are contravariant while properties are covariant comes down to a tradeoff between type safety and usability.

Function arguments being contravariant makes sense because you can only safely call a function with a subtype of the argument, not a base type.

class Animal { eat() { } }
class Dog extends Animal { wof() { } }

type Fn<T> = (p: T) => void
var animalFn: Fn<Animal> = a => a.eat();
var dogFn: Fn<Dog> = d => { d.eat(); d.wof() }
dogFn(new Animal()) // error, invoking d.wof would fail 
animalFn = dogFn; // thus, this also fails

animalFn(new Dog()) // This is okay
dogFn = animalFn; // this is also okay

Playground Link

As for why properties are covariant, the explanation is slightly more complex. Essentially, a field position like { a: T } would result in an invariant type, but that approach could be challenging. Therefore, in TypeScript, by definition, a field type position (as seen in T) renders the type covariant in that field type (thus, { a: T } is covariant in T). While we could demonstrate how a being read-only results in covariance and write-only leads to contravariance, combining both scenarios gives us invariance. However, I'll leave you with an example where default covariant behavior can cause runtime errors even in correctly typed code:

type SomeType<T> = { a: T }

function foo(a: SomeType<{ foo: string }>) {
    a.a = { foo: "" } // no bar here, not needed
}
let b: SomeType<{ foo: string, bar: number }> = {
    a: { foo: "", bar: 1 }
}

foo(b) // valid since T is in a covariant position, making SomeType<{ foo: string, bar: number }> assignable to SomeType<{ foo: string }>
b.a.bar.toExponential() // Runtime error as nobody in foo assigned bar

Playground Link

You may also find my post on variance in TypeScript interesting by clicking here.

Answer 2

Your keen observation about one of the examples resulting in never is accurate, and you are not overlooking any compiler settings. In more recent TypeScript versions, intersections of primitive types lead to a resolution of never. If you switch back to an older version, you will still observe string & number. The newer version showcases contravariant position behavior when using object types:

type Bar<T> = T extends { a: (x: infer U) => void, b: (x: infer U) => void } ? U : never;
type T21 = Bar<{ a: (x: { h: string }) => void, b: (x: { g: number }) => void }>;  // {h: string; } & { g: number;}

Playground Link

The reason why function parameters are contravariant while properties are covariant comes down to a tradeoff between type safety and usability.

Function arguments being contravariant makes sense because you can only safely call a function with a subtype of the argument, not a base type.

class Animal { eat() { } }
class Dog extends Animal { wof() { } }

type Fn<T> = (p: T) => void
var animalFn: Fn<Animal> = a => a.eat();
var dogFn: Fn<Dog> = d => { d.eat(); d.wof() }
dogFn(new Animal()) // error, invoking d.wof would fail 
animalFn = dogFn; // thus, this also fails

animalFn(new Dog()) // This is okay
dogFn = animalFn; // this is also okay

Playground Link

As for why properties are covariant, the explanation is slightly more complex. Essentially, a field position like { a: T } would result in an invariant type, but that approach could be challenging. Therefore, in TypeScript, by definition, a field type position (as seen in T) renders the type covariant in that field type (thus, { a: T } is covariant in T). While we could demonstrate how a being read-only results in covariance and write-only leads to contravariance, combining both scenarios gives us invariance. However, I'll leave you with an example where default covariant behavior can cause runtime errors even in correctly typed code:

type SomeType<T> = { a: T }

function foo(a: SomeType<{ foo: string }>) {
    a.a = { foo: "" } // no bar here, not needed
}
let b: SomeType<{ foo: string, bar: number }> = {
    a: { foo: "", bar: 1 }
}

foo(b) // valid since T is in a covariant position, making SomeType<{ foo: string, bar: number }> assignable to SomeType<{ foo: string }>
b.a.bar.toExponential() // Runtime error as nobody in foo assigned bar

Playground Link

You may also find my post on variance in TypeScript interesting by clicking here.

Contrasting covariant and contravariant positions within Typescript

Answer №1

Similar questions

Managing event date changes in Angular PrimeNG FullCalendar

In Typescript, we can streamline this code by assigning a default value of `true` to `this.active` if `data.active

TS2604: The JSX element '...' lacks any construct or call signatures and is unable to be processed

The challenge with the Optional Chaining operator in Typescript 3.7@beta

Adding a second interface to a Prop in Typescript React: a step-by-step guide

Caution: The attribute name `data-*` is not recognized as valid

What is the best approach for testing the TypeScript code below?

Troubleshooting: Angular 6 Renderer2 Issue with Generating Dynamic DOM Elements for SELECT-Option

Do I have to wait for the HTTP get request to access the fetched object property?

Using the `window` object in Jasmine with Angular, a mock can be created for testing purposes

The module cannot be located: Unable to find '../typings' in '/vercel/path0/pages'

What is the process for initiating an Angular 2 Materialize component?

Troubleshooting the issue with the HTTPClient get method error resolution

What is the best way to customize a button component's className when importing it into another component?

Upgrade Angular from 12 to the latest version 13

Struggling to successfully pass a function as an argument to the setTimeout method within an array in node.js using TypeScript

How can you define the types of function arguments when destructuring arguments in TypeScript?

Exploring the benefits of using getServerSideProps with NextJS and Typescript for

Choosing the initial choice with ngFor: A step-by-step guide

A guide to implementing vue-i18n in Vue class components