TypeScript struggles with accurately inferring type when a type alias is utilized

Question

TypeScript struggles with accurately inferring type when a type alias is utilized

Within the code snippet provided, there are two instances of a Record<string, string[]>. One declares itself directly as the Record, while the other uses a type alias that refers to the same Record type. When these are passed into a function along with an empty array (expected to be inferred as an empty string array by TypeScript), the first instance compiles successfully, but the second does not. This issue seems to arise from the type alias causing a problem. Is there a workaround for this situation? Should this be reported as a bug in TypeScript?

function foo<T>(record: Record<string, T>, entity: T) {
}

type StringArrayRecord = Record<string, string[]>;

function test() {
    const working: Record<string, string[]> = {};
    foo(working, []); // Compiles

    const broken: StringArrayRecord = {};
    foo(broken, []); // Does not compile
}

The error message is as follows:

Argument of type 'StringArrayRecord' is not assignable to parameter of type 'Record<string, never[]>'.
  'string' index signatures are incompatible.
    Type 'string[]' is not assignable to type 'never[]'.
      Type 'string' is not assignable to type 'never'.

If an alternate type is used instead of string[] as the second type parameter in the record, the same issue occurs whenever there is ambiguity in the type (such as a union type), for example:

type StringOrNumberRecord = Record<string, string | number>;

function test() {
    const working: Record<string, string | number> = {};
    foo(working, "string"); // Compiles

    const broken: StringOrNumberRecord = {};
    foo(broken, "string"); // Does not compile
}

(This behavior persists in both TypeScript 4.8 and 5.)

(One potential solution is to explicitly specify the type of the second parameter when calling foo, such as

foo(broken, "string" as string | number);

. Another option is to specify the generic type parameter when invoking foo, like

foo<string | number>(broken, "string")

. However, it seems that neither of these should be necessary.)

typescript typescript-generics

Answer 1

Answer №1

It seems that everything is functioning as expected, based on information from microsoft/TypeScript#54000. It does appear odd, however, when a type alias has such a significant impact on inference.

The discrepancy arises because, in TypeScript, when comparing two types, the compiler often needs to recursively match various components of each type before determining if they are identical, different, or if one can be used to infer parts of the other.

If both types are defined using an identical generic type with known variance in its type parameter (referenced in this article about variance in TypeScript: Difference between Variance, Covariance, Contravariance, Bivariance and Invariance in TypeScript), then the compiler can optimize by simply comparing the type arguments. For instance, if it's comparing F<string> to F<unknown> for the following F<T> type:

type F<T> = {
  prop: T;
  otherProp: string;
  anotherProp: number;
  // ... additional properties not dependent on T
}

which the compiler has determined to be covariant in its type parameter, it can directly conclude that F<string> is a subtype of F<unknown>, without needing to fully evaluate and compare them.

This shortcut essentially provides a quicker means to reach the same result obtained through a more extensive evaluation process.

Conversely, when the compiler compares F<string> to G where G is defined as:

type G = F<unknown>

it would need to evaluate the types further before making a comparison. By substituting string into F and then evaluating G, it becomes evident that a full comparison of properties in both types is required.

Eventually, it will determine that F<string> is a subtype of G, but via a different route.

(You could also replace F<T> with Record<string, T> and G with Record<string, string[]> here.)

Although these approaches yield similar outcomes, there are observable distinctions. One notable difference is its impact on generic type argument inference.

For instance, when inferring Record<string, T> from a value of Record<string, string[]> while simultaneously inferring T from a value of never[], the compiler utilizes the variance marker on Record's second type parameter to prioritize inferring string[] over never[] due to assignability.

In contrast, when inferring Record<string, T> from a value of type StringOrNumberRecord alongside inferring T from never[], the compiler cannot utilize variance markings as a shortcut. It must fully evaluate

StringOrNumberRecord</code, leading to higher priority for the direct inference candidate of <code>never[]

.

While this inconsistency may seem unfortunate, neither approach is inherently "wrong." According to comments from the TS team dev lead, a more consistent solution would involve reducing the variance marker priority, potentially resulting in both calls failing – a scenario likely unsatisfactory to all parties involved. Therefore, the current behavior stands as is for now.

Answer 2

It seems that everything is functioning as expected, based on information from microsoft/TypeScript#54000. It does appear odd, however, when a type alias has such a significant impact on inference.

The discrepancy arises because, in TypeScript, when comparing two types, the compiler often needs to recursively match various components of each type before determining if they are identical, different, or if one can be used to infer parts of the other.

If both types are defined using an identical generic type with known variance in its type parameter (referenced in this article about variance in TypeScript: Difference between Variance, Covariance, Contravariance, Bivariance and Invariance in TypeScript), then the compiler can optimize by simply comparing the type arguments. For instance, if it's comparing F<string> to F<unknown> for the following F<T> type:

type F<T> = {
  prop: T;
  otherProp: string;
  anotherProp: number;
  // ... additional properties not dependent on T
}

which the compiler has determined to be covariant in its type parameter, it can directly conclude that F<string> is a subtype of F<unknown>, without needing to fully evaluate and compare them.

This shortcut essentially provides a quicker means to reach the same result obtained through a more extensive evaluation process.

Conversely, when the compiler compares F<string> to G where G is defined as:

type G = F<unknown>

it would need to evaluate the types further before making a comparison. By substituting string into F and then evaluating G, it becomes evident that a full comparison of properties in both types is required.

Eventually, it will determine that F<string> is a subtype of G, but via a different route.

(You could also replace F<T> with Record<string, T> and G with Record<string, string[]> here.)

Although these approaches yield similar outcomes, there are observable distinctions. One notable difference is its impact on generic type argument inference.

For instance, when inferring Record<string, T> from a value of Record<string, string[]> while simultaneously inferring T from a value of never[], the compiler utilizes the variance marker on Record's second type parameter to prioritize inferring string[] over never[] due to assignability.

In contrast, when inferring Record<string, T> from a value of type StringOrNumberRecord alongside inferring T from never[], the compiler cannot utilize variance markings as a shortcut. It must fully evaluate

StringOrNumberRecord</code, leading to higher priority for the direct inference candidate of <code>never[]

.

While this inconsistency may seem unfortunate, neither approach is inherently "wrong." According to comments from the TS team dev lead, a more consistent solution would involve reducing the variance marker priority, potentially resulting in both calls failing – a scenario likely unsatisfactory to all parties involved. Therefore, the current behavior stands as is for now.

Answer 3

Answer №2

The main problem arises from the lack of specification for the type T in the function foo when it is called:

// The generic type T is defined here
function foo<T>(record: Record<string, T>, entity: T) {
}

// The variable 'broken' has the type Record<string, string[]>
const broken: StringArrayRecord = {};

foo(broken, []); // Compilation fails due to unknown type for []

Can you spot the issue? The second parameter passed as [] results in an empty and untyped array in Typescript, leading to a type mismatch.

If you replace the empty array with an empty string like this:

foo(broken, [""]);

The compiler can correctly infer the parameters as string[], resolving the issue smoothly.

Answer 4

The main problem arises from the lack of specification for the type T in the function foo when it is called:

// The generic type T is defined here
function foo<T>(record: Record<string, T>, entity: T) {
}

// The variable 'broken' has the type Record<string, string[]>
const broken: StringArrayRecord = {};

foo(broken, []); // Compilation fails due to unknown type for []

Can you spot the issue? The second parameter passed as [] results in an empty and untyped array in Typescript, leading to a type mismatch.

If you replace the empty array with an empty string like this:

foo(broken, [""]);

The compiler can correctly infer the parameters as string[], resolving the issue smoothly.

TypeScript struggles with accurately inferring type when a type alias is utilized

Answer №1

Answer №2

Similar questions

Using TypeScript: creating functions without defining an interface

Integrating TypeScript into an established create-react-app project

The Array of Objects is not being generated from Action and Effects

I am trying to figure out how to send a One Signal notification from my Ionic app using the One Signal REST API. I have reviewed the documentation, but I am still unable to understand it

Utilizing .js file alongside declaration files .d.ts in Angular: A guide

What is the best way to sort through custom components within children in Solid JS?

Adding new information to a list when a button is clicked: Combining Angular TypeScript with Laravel

Each professional has their own unique workdays and hours, which are easily managed with the angular schedule feature

Exploring TypeScript's Classes and Generics

The function Array.foreach is not available for type any[]

React development: How to define functional components with props as an array but have them recognized as an object

When quickly swiping, the button may not respond to the initial click

Reselect.createSelector() function in Typescript compiler returns incorrect type definition

The specified object is not extensible, hence the property effectTag cannot be added

There was an error encountered: Uncaught TypeError - Unable to access the 'append' property of null in a Typescript script

Declaration File for TypeScript External Node Module Typings

showing the current time and including extra minutes

Oops, it seems like there was an issue with NextJS 13 Error. The createContext functionality can only be used in Client Components. To resolve this, simply add the "use client" directive at the

What is causing the large build size when using Webpack with Vue.js?

Subscriber fails to receive updates from Behavior subject after calling .next(value)