What kind of parameter can be specified for a generic method that will not actually be called?

Question

What kind of parameter can be specified for a generic method that will not actually be called?

Currently, I am attempting to create a method that includes a parameter with a generic type. In this case, I have used 'unknown' as the generic type since it is not needed:

function f(op: Operation<unknown>): void {...}

. However, this approach does not work in all scenarios, especially if the Operation class uses its generic type in a method signature.

Interestingly, when I directly utilize a generic Context member instead of incorporating it in a method's parameter, the code compiles without any errors.

I am seeking insights into why I am encountering issues using 'unknown' when the generic type is part of a method's signature.

The following example illustrates the problem:

export interface Operation<Context> {
    process: (context: Context) => void;
    //context: Context;
    n: number;
}

type MyContext = {
  info: string;
}

const op : Operation<MyContext> = {
  process: (context: MyContext) => { console.log("process", context.info); },
  //context: {info:"context.info"},
  n: 42
}

function fGeneric<Context>(op: Operation<Context>): void {
     console.log("fGeneric", op.n);
}

console.log(fGeneric(op));

function fUnknown(op: Operation<unknown>): void {
     console.log("fUnknown", op.n);
}

console.log(fUnknown(op)); 
// Argument of type 'Operation<MyContext>' is not assignable to parameter of type 'Operation<unknown>'.
// Type 'unknown' is not assignable to type 'MyContext'.

If 'process' is commented out and 'context' is uncommented, the code compiles without any error.

(Note: This example has been simplified to highlight the issue at hand.)

Playground: https://www.typescriptlang.org/play?ts=4.9.5#code/KYDwDg9gTgLgBASwHY2FAZgQwMbDgeTDUxgQiQB4Bhc1EGAPjgG8AoODuMKCXAZz4AuOAApstUDGE0UkgJRwAvEwBuEBABMA3O04B6PeNn1pE+js5wkgpAFcAtgCM0OgL6tWMAJ5E4AWS8ZOnhFFl1kdAhhPhgoZABzNw8jGLgIMDhhQmJScgoAoMkmULYObl5gAWExMyl-QNqFZRY4FIgAG2AAOnaIeJEAInL+PgGAGiNgroiIOS04VzHdA0nJYWZEJEjBAdX6aa2IAYWljmsAFgAmVndWdFskbFykOHQAcWAkNARsalqGETpLJEKAkMiUQr0BhyYRqTRhSytch8DrdXr9AbvT7fbDjNJgLpIOY3ZLI1E9PoiLFfOLYQFgOTEu4PJ7g14AVSQAGskBAAO5IenAnLgigPHn8pDQ2HqDQIyxtToUjHoTkSgV49KE4m3RVoymq7m8gX0xlaIA

typescript typescript-generics contravariance

Answer 1

Answer №1

Opt for using the lower type rather than the upper type.

unknown represents the top type, encompassing all possible values. A function that accepts an argument of type unknown should be able to handle any value as the argument. On the contrary, a function that only accepts certain types cannot fulfill the requirements of (_: unknown) => void; however, a function (_: unknown) => void will align with (_: T) => void for any T. Thus, we observe that T is a subtype of unknown, while (_: unknown) => void is a subtype of (_: T) => void. This scenario is referred to as contravariance, indicating that the type constructor taking T to a type of functions that accept a T input is contravariant in T.

In this context, given that the definition of Operation<T> specifies a property consisting of functions accepting T, Operation<T> also exhibits contravariance in T. Consequently, Operation<unknown> serves as a subtype of Operation<T> for any other T, not a supertype as desired. (Upon modifying Operation<T> to include solely a property of type T, it transitions into being covariant in T, resulting in the reversal of the subtype relationship.)

Instead, consider utilizing Operation<never>:

export interface Operation<Context> {
    process: (context: Context) => void;
    n: number;
}

type MyContext = {
    info: string;
}

const op : Operation<MyContext> = {
    process: (context: MyContext) =>
        { console.log("process", context.info); },
    n: 42
}

function fNever(op: Operation<never>): void {
    console.log("fNever", op.n);
}

console.log(fNever(op));

The bottom type never contains no values and qualifies as a subtype of all types. Since Operation<T> demonstrates contravariance in T, this signifies that Operation<never> acts as a supertype of all Operation<T>. To simplify, by employing an Operation<never>, you are not restricting process to be callable with specific inputs, essentially pledging to never invoke

process</code at all: since <code>never

encompasses no values, a function accepting a never parameter becomes uncallable.

Answer 2

Opt for using the lower type rather than the upper type.

unknown represents the top type, encompassing all possible values. A function that accepts an argument of type unknown should be able to handle any value as the argument. On the contrary, a function that only accepts certain types cannot fulfill the requirements of (_: unknown) => void; however, a function (_: unknown) => void will align with (_: T) => void for any T. Thus, we observe that T is a subtype of unknown, while (_: unknown) => void is a subtype of (_: T) => void. This scenario is referred to as contravariance, indicating that the type constructor taking T to a type of functions that accept a T input is contravariant in T.

In this context, given that the definition of Operation<T> specifies a property consisting of functions accepting T, Operation<T> also exhibits contravariance in T. Consequently, Operation<unknown> serves as a subtype of Operation<T> for any other T, not a supertype as desired. (Upon modifying Operation<T> to include solely a property of type T, it transitions into being covariant in T, resulting in the reversal of the subtype relationship.)

Instead, consider utilizing Operation<never>:

export interface Operation<Context> {
    process: (context: Context) => void;
    n: number;
}

type MyContext = {
    info: string;
}

const op : Operation<MyContext> = {
    process: (context: MyContext) =>
        { console.log("process", context.info); },
    n: 42
}

function fNever(op: Operation<never>): void {
    console.log("fNever", op.n);
}

console.log(fNever(op));

The bottom type never contains no values and qualifies as a subtype of all types. Since Operation<T> demonstrates contravariance in T, this signifies that Operation<never> acts as a supertype of all Operation<T>. To simplify, by employing an Operation<never>, you are not restricting process to be callable with specific inputs, essentially pledging to never invoke

process</code at all: since <code>never

encompasses no values, a function accepting a never parameter becomes uncallable.

Answer 3

Answer №2

It is not possible to pass an Operation<MyContext> to a function that expects a parameter of type Operation<unknown>, as the function could potentially make unauthorized changes to the parameter. For example:

function fUnknown(op: Operation<unknown>): void {
    const foo: unknown = "Mystery";
    op.context = foo;
    console.log("fUnknown", op.n);
}

A better approach would be to handle it like this instead:

function fUnknown2<T extends unknown>(op: Operation<T>): void {
    const foo: unknown = "Mystery";
    /* This would result in the error message "Type 'unknown' is not assignable to type 'T'.
  'unknown' is assignable to the constraint of type 'T', but 'T' could be instantiated with a different subtype of constraint 'unknown'."
    op.context = foo; */
    console.log("fUnknown", op.n);
}

Answer 4

It is not possible to pass an Operation<MyContext> to a function that expects a parameter of type Operation<unknown>, as the function could potentially make unauthorized changes to the parameter. For example:

function fUnknown(op: Operation<unknown>): void {
    const foo: unknown = "Mystery";
    op.context = foo;
    console.log("fUnknown", op.n);
}

A better approach would be to handle it like this instead:

function fUnknown2<T extends unknown>(op: Operation<T>): void {
    const foo: unknown = "Mystery";
    /* This would result in the error message "Type 'unknown' is not assignable to type 'T'.
  'unknown' is assignable to the constraint of type 'T', but 'T' could be instantiated with a different subtype of constraint 'unknown'."
    op.context = foo; */
    console.log("fUnknown", op.n);
}

Answer 5

Answer №3

The compilation error arises due to the contravariance of function parameters, where Operation utilizes the Context type parameter in a position that contradicts the expected behavior.

When you provide op to fUnknown, op insists on being compatible only with MyContext, whereas fUnknown necessitates the Operation to be adaptable with any context, not limited to just MyContext.

To address this issue, there are several potential solutions:

Demand Operation<any>: If the generic information is irrelevant in both the body of the function and the rest of the signature, this approach is perfectly acceptable.
Enforce Operation<MyContext>: This option may lack versatility.
Require Operation<T> and allow inference for T: By passing op, T automatically becomes MyContext, enabling you to utilize the fact that T is a generic type within the function's body and signature.

Answer 6

The compilation error arises due to the contravariance of function parameters, where Operation utilizes the Context type parameter in a position that contradicts the expected behavior.

When you provide op to fUnknown, op insists on being compatible only with MyContext, whereas fUnknown necessitates the Operation to be adaptable with any context, not limited to just MyContext.

To address this issue, there are several potential solutions:

Demand Operation<any>: If the generic information is irrelevant in both the body of the function and the rest of the signature, this approach is perfectly acceptable.
Enforce Operation<MyContext>: This option may lack versatility.
Require Operation<T> and allow inference for T: By passing op, T automatically becomes MyContext, enabling you to utilize the fact that T is a generic type within the function's body and signature.

What kind of parameter can be specified for a generic method that will not actually be called?

Answer №1

Answer №2

Answer №3

Similar questions

Avoid starting the stopwatch and timer at the same time

Incorporate a generic type into a React Functional Component

Switch on ngbAccordion via TypeScript File

In an Electron-React-Typescript-Webpack application, it is important to note that the target is not a DOM

Discovering the Java Map's value in Typescript

You cannot call this expression. The type '{}' does not have any callable signatures. Error TS2349

Bringing in manageable RxJS operators

Expanding User Type to Include Extra User Data Using NextAuth.js

Transfer the rxjs operator takeUntil to its own method

Creating a Modal using Typescript with NextJS

Tips on streamlining two similar TypeScript interfaces with distinct key names

What does 'this' refer to in a JavaScript function that is inside an object?

Setting up systemjs.config.js for utilizing relative paths within IIS - A step-by-step guide

The UI elements are failing to reflect the changes in the data

Submitting Angular 4 Form Reset Sends Data to Server

ESLint not functioning properly on TypeScript (.ts and .tsx) files within Visual Studio Code

The absence of type-safety in the MUI System sx is a glaring issue

Error occurs in the compiler when a variable is utilized as a function

Angular 4: Exploring the Depths of Nested HTTP Requests

The element is inferred to have an 'any' type due to the fact that a 'string' type expression cannot be used to access elements in the type '{ Categories: Element; Admin: Element; }'