Is it logical for `string & any[]` to lead to a `never` result?

Question

Is it logical for `string & any[]` to lead to a `never` result?

There's something peculiar going on with TypeScript. I have a type union that includes array types (string[], number[]) and non-array types (string, number). When using type inference, everything behaves as expected:

type bar = string | number | string[] | number[];
declare foo: bar;

if (Array.isArray(foo))
{
    foo // string[] | number[]
}
else
{
    foo // string | number
}

However, when attempting to constrain the type directly to array types using a type intersection, the outcome is unexpected:

declare foo: bar & any[];

// expected type: string[] | number[]

foo // (string & any[]) | (number & any[]) | (string[] & any[]) | (number[] & any[])

Why does this happen?
Shouldn't string & any[] result in never and string[] & any[] in string[]?

[link to playground]

typescript

Answer 1

Answer №1

It is logical to assume that when completely different types intersect, the result should be 'never', as the intersection of two non-overlapping sets is empty. This concept has been brought up previously (see ms/TS#18210) on several occasions.

Since TypeScript 2.6, there has been a partial implementation where types like "a" | "b" & "c" become 'never', while "a" & "c" do not. This was done to prevent unions and intersections from creating excessively large union types.

The decision of why this isn't always applied can be found in the pull request introducing the implementation, with insights from Anders Hejlsberg, one of the key figures behind TypeScript. One reason mentioned is not wanting to disrupt code that uses intersections for tagging primitive types.

Another reason discussed is to make it easier to identify the origin of certain types, such as when object types intersect with properties of the same name.

In conclusion, potential performance impacts are also a major consideration for implementing new features in the compiler, as aggressive checks for reducing intersections to 'never' could have a significant impact on performance.

Answer 2

It is logical to assume that when completely different types intersect, the result should be 'never', as the intersection of two non-overlapping sets is empty. This concept has been brought up previously (see ms/TS#18210) on several occasions.

Since TypeScript 2.6, there has been a partial implementation where types like "a" | "b" & "c" become 'never', while "a" & "c" do not. This was done to prevent unions and intersections from creating excessively large union types.

The decision of why this isn't always applied can be found in the pull request introducing the implementation, with insights from Anders Hejlsberg, one of the key figures behind TypeScript. One reason mentioned is not wanting to disrupt code that uses intersections for tagging primitive types.

Another reason discussed is to make it easier to identify the origin of certain types, such as when object types intersect with properties of the same name.

In conclusion, potential performance impacts are also a major consideration for implementing new features in the compiler, as aggressive checks for reducing intersections to 'never' could have a significant impact on performance.

Answer 3

Answer №2

When dealing with union types, the distribution of intersections becomes apparent. For example, intersecting a union A | B | C with something like D results in

A & D | B & D | C & D

.

type U = A | B | C;
type Z = U & D; // distributed as A & D | B & D | C & D

It's important to note that intersection types do not get "collapsed," as demonstrated by

type X = Array<number> & Array<any>;

. The type remains as originally declared.

This behavior is consistent regardless of whether the intersection type leads to a scenario where never is expected or not. For instance,

type X = { x: string } & { y: string };

will not be collapsed into { x: string, y: string }

The compiler steps in to restrict your intersection when you try to assign something that does not satisfy the type.

For example:

type X = Array<number> & Array<any>; // type remains unchanged
const x: X = ['some string']; // this will trigger an error
const y: X = [4]; // this is valid

To refine your type, consider using a conditional type instead of an intersection to filter the union.

type Bar = string | number | string[] | number[];

declare const foo: Exclude<Bar, Array<any>>; // results in string | number

Answer 4

When dealing with union types, the distribution of intersections becomes apparent. For example, intersecting a union A | B | C with something like D results in

A & D | B & D | C & D

.

type U = A | B | C;
type Z = U & D; // distributed as A & D | B & D | C & D

It's important to note that intersection types do not get "collapsed," as demonstrated by

type X = Array<number> & Array<any>;

. The type remains as originally declared.

This behavior is consistent regardless of whether the intersection type leads to a scenario where never is expected or not. For instance,

type X = { x: string } & { y: string };

will not be collapsed into { x: string, y: string }

The compiler steps in to restrict your intersection when you try to assign something that does not satisfy the type.

For example:

type X = Array<number> & Array<any>; // type remains unchanged
const x: X = ['some string']; // this will trigger an error
const y: X = [4]; // this is valid

To refine your type, consider using a conditional type instead of an intersection to filter the union.

type Bar = string | number | string[] | number[];

declare const foo: Exclude<Bar, Array<any>>; // results in string | number

Is it logical for `string & any[]` to lead to a `never` result?

Answer №1

Answer №2

Similar questions

Steps to fill a select dropdown with numbers ranging from 1 to 10, ensuring that each number has a distinct index or value

Mastering React Composition: Leveraging Parent Methods

Guide on Retrieving an Array from an Observable

Enhance the TypeScript interface by dynamically appending new fields with specific naming conventions

Utilize a type that is not made available for export

Displaying data from an Angular subscription in a user interface form

Is there a way to increase the level of detail in the error trace provided by tsc? This error trace is

Encountering a TypeError while working with Next.js 14 and MongoDB: The error "res.status is not a function"

Create an interface that adheres to the defined mapped type

Exploring two main pages, each with tabs displaying two negative behaviors

Update the sorting icon in the data grid using Material-UI

Utilize string generic limitations as dynamically generated key

`Can incompatible Typescript types be allowed for assignment?`

Tips for displaying a hyperlink in an Angular 6 component template

alteration of a function through TypeScript

Create a recursive array structure that contains two distinct data types and specific guidelines

When executing npm run build, the fonts are not displayed properly in Vite

Using Typescript to add an element to a specific index in an array

Oops! An unexpected error occurred while parsing the JSON response

Encountering issues while passing variables in Vue 3 using TypeScript