Is subtyping causing issues in TypeScript's inheritance model?

Question

Is subtyping causing issues in TypeScript's inheritance model?

I am currently utilizing TypeScript for my coding projects, and I have observed that it can allow the production of non-type-safe code. Despite implementing all the "strict" options available to me, the behavior I am experiencing goes against the principle of "Inheritance implies subtyping". This issue has been discussed in various platforms, such as:

https://stackoverflow.com/questions/50729485/override-method-with-different-argument-types-in-extended-class-typescript

One specific piece of code that does not raise any type errors is as follows:

abstract class A {
    abstract do(x: number | string): number;
}

class B extends A {
    override do(x: number): number {
        return x;
    }
}

const a: A = new B();

const x: number = a.do("dupa");

console.log(x);

Instead of receiving an expected error message like:

Error:(7, 14) TS2416: Property 'do' in type 'B' is not assignable to the same property in base type 'A'.
  Type '(x: number) => number' is not assignable to type '(x: string | number) => number'.
    Types of parameters 'x' and 'x' are incompatible.
      Type 'string | number' is not assignable to type 'number'.
        Type 'string' is not assignable to type 'number'.

The output actually displays "dupa" in the console.

In attempt to troubleshoot this issue, I tried switching types (X, Y) from (number, string) to different pairs under the assumption that there might be implicit casting involved. However, even with pairs of arbitrary or non-assignable types X and Y, or with some combination where X and Y=null (while working with strictNullChecks), I encountered the same outcome.

Furthermore, I was able to deliberately create a type error

Type 'string | number' is not assignable to type 'number'.   Type 'string' is not assignable to type 'number'.

. Hence, in general, such assignments should not be permitted.

It appears that this behavior could potentially be considered as a "feature rather than a bug", as indicated in: https://github.com/microsoft/TypeScript/issues/22156

Thus, I am now seeking to rephrase the inquiry:

Is there a workaround available that would prompt the TypeScript type checker to detect the absence of contravariance in parameter types within overridden methods?

typescript inheritance subtyping

Answer 1

Answer №1

To achieve true soundness and type-safety in TypeScript, it would be necessary for the language to compare function and method parameters contravariantly. This would ensure that method overrides only widen parameter types without narrowing them. However, TypeScript is not designed to be truly sound, as stated in the TypeScipt design goals. The goal is to balance correctness and productivity rather than aim for a provably correct type system.

In TypeScript, method parameters are compared bivariantly, allowing both widening and narrowing of parameter types when overriding methods. Even though non-method function types became strict with the introduction of the --strictFunctionTypes compiler option, method parameters remain bivariant regardless of this setting.

There are reasons behind this decision, one being that developers often want to treat arrays covariantly, leading to potential unsound behavior. Similar unsoundness exists with properties in TypeScript, where covariance can lead to unexpected runtime errors.

Enforcing soundness for methods while properties remain unsound creates inconsistencies in the language. Therefore, TypeScript continues to allow unsafe method overrides but restricts standalone functions and callback function types.

If you need a workaround, consider using function-valued properties instead of methods in your code. This can help avoid conflicts with method overrides by defining these functions syntactically within your type definitions.

interface A {
    do: (x: number | string) => number;
}

class B implements A {
    do(x: number): number { // error!
        return x;
    }
}

You could also use abstract classes with overridden function properties instead of methods to maintain the structure required by your code:

abstract class A {
    abstract do: (x: number | string) => number;
}

class B extends A {
    override do = function (x: number) { // error            
        return x;
    }
}

For more information on working around TypeScript limitations, check out the provided Playground link which showcases different approaches to handling type-related issues.

Answer 2

To achieve true soundness and type-safety in TypeScript, it would be necessary for the language to compare function and method parameters contravariantly. This would ensure that method overrides only widen parameter types without narrowing them. However, TypeScript is not designed to be truly sound, as stated in the TypeScipt design goals. The goal is to balance correctness and productivity rather than aim for a provably correct type system.

In TypeScript, method parameters are compared bivariantly, allowing both widening and narrowing of parameter types when overriding methods. Even though non-method function types became strict with the introduction of the --strictFunctionTypes compiler option, method parameters remain bivariant regardless of this setting.

There are reasons behind this decision, one being that developers often want to treat arrays covariantly, leading to potential unsound behavior. Similar unsoundness exists with properties in TypeScript, where covariance can lead to unexpected runtime errors.

Enforcing soundness for methods while properties remain unsound creates inconsistencies in the language. Therefore, TypeScript continues to allow unsafe method overrides but restricts standalone functions and callback function types.

If you need a workaround, consider using function-valued properties instead of methods in your code. This can help avoid conflicts with method overrides by defining these functions syntactically within your type definitions.

interface A {
    do: (x: number | string) => number;
}

class B implements A {
    do(x: number): number { // error!
        return x;
    }
}

You could also use abstract classes with overridden function properties instead of methods to maintain the structure required by your code:

abstract class A {
    abstract do: (x: number | string) => number;
}

class B extends A {
    override do = function (x: number) { // error            
        return x;
    }
}

For more information on working around TypeScript limitations, check out the provided Playground link which showcases different approaches to handling type-related issues.

Answer 3

Answer №2

There appears to be a common saying in the coding world, that it's more of a feature than a bug, as detailed here:

https://github.com/microsoft/TypeScript/issues/22156

This revelation is disheartening: even with strict flags enabled (such as strict and strictFunctionTypes), you may end up with error-free code that simply does not function properly due to a type error.

Answer 4

There appears to be a common saying in the coding world, that it's more of a feature than a bug, as detailed here:

https://github.com/microsoft/TypeScript/issues/22156

This revelation is disheartening: even with strict flags enabled (such as strict and strictFunctionTypes), you may end up with error-free code that simply does not function properly due to a type error.

Is subtyping causing issues in TypeScript's inheritance model?

Answer №1

Answer №2

Similar questions

Issue: Unable to locate a matching object '[object Object]' of type 'object'. NgFor can solely bind to data structures like Arrays and Iterables

Tips for resolving this unhandled error in React TypeScript

Enhancing Angular input validators with updates

How can you enhance a component by including additional props alongside an existing onClick function?

Is it necessary to manually unsubscribe from observables in the main Angular component?

Ensuring Commitments in the ForEach Cycle (Typescript 2)

Ways to redirect to a different page following a successful execution of a mutation in React-query

Tips for refining TypeScript discriminated unions by using discriminators that are only partially known?

Refreshing the cache in SWR, but the user interface remains unchanged inexplicably - SWR hook in Next.js with TypeScript

What are some effective ways to exclude multiple spec files in playwright?

The custom native date adapter is facing compatibility issues following the upgrade of Angular/Material from version 5 to 6

Encountering an Unexpected Index Error with ngFor in Angular 4/5

What is the expected return type in TypeScript of a function that returns a void function?

Exploring Opencascade.js: Uncovering the Real Text within a TCollection_ExtendedString

Using React with an Array of Promises in Typescript

The server's response is unpredictable, causing Json.Parse to fail intermittently

Angular2: Once user is authenticated, navigate to specific routes

The Ion-item-option button requires two clicks to activate

Is it possible to showcase a variety of values in mat-select?

Create a functioning implementation for retrieving a list of objects from a REST API