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

Extract the values from HTTP GET request by Id (Observable) and assign them to variables within the component

Issues with TypeScript bundling external modules

Learn how to dynamically disable a button based on the input state matching an email pattern!

Typescript types can inadvertently include unnecessary properties

The feature of getDisplayMedia is not included in TypeScript 3.8

Can all objects within an interface be iterated through in order to retrieve both the key and its corresponding value?

When utilizing AngularFire with Firebase Firestore Database, users may encounter instances where data duplication occurs on

Distinguishing between TypeScript versions 2.0.x and 2.1.x using type definitions and filtering with a switch/case statement

Storing information in an array based on a specific flag

Utilizing a setup module for configuration purposes

Restrict the frequency of requests per minute using Supertest

Creating a ref with Typescript and styled-components: A comprehensive guide

Connecting RxJS Observables with HTTP requests in Angular 2 using TypeScript

A guide on applying color from an API response to the border-color property in an Angular application

Initializing ngOnInit and saving the value to an array variable

What is causing the issue with TypeScript's React.createRef() and its compatibility with the material-ui Button element?

Utilizing a segment of one interface within another interface is the most effective method

Storing references to the DOM elements external to the rendering component

Object data is not being received by the defaultValue in React Hook Form

Pausing or buffering an RxJS 6 observable when the page is inactive