How come I am able to use array.some() but not array.every() when working with union array types?

Question

How come I am able to use array.some() but not array.every() when working with union array types?

Imagine a scenario where there is a (silly) function like this:

function doSomething(input: number|string): boolean {
  if (input === 42 || input === '42') {
    return true;
  } else {
    return false;
  }
}

Question arises as to why array.some() can be called like this:

function doSomethingWithArray(input: number[]|string[]): boolean {
  return input.some(i => doSomething(i));
}

However, calling array.every() in the same manner results in an error:

function doEverythingWithArray(input: number[]|string[]): boolean {
  return input.every(i => doSomething(i));
}

This generates the following error message:

This expression is not callable. Each member of the union type '{ (predicate: (value: number, index: number, array: number[]) => value is S, thisArg?: any): this is S[]; (predicate: (value: number, index: number, array: number[]) => unknown, thisArg?: any): boolean; } | { ...; }' has signatures, but none of those signatures are compatible with each other.

The difference between the two scenarios is puzzling. Logically, both should either work or fail. What could potentially be overlooked?

Note that doSomething() accepts number|string as its argument, hence it should operate with every element of number[]|array[], similar to how it functions with array.some(), right?

arrays typescript

Answer 1

Answer №1

This is a current limitation within TypeScript; reference microsoft/TypeScript#44373 for more information.

In the past, TypeScript struggled with invoking methods on a combination of array types. Initially, calling unions-of-functions was not allowed due to the challenge of merging multiple signatures into one coherent function. Check out microsoft/TypeScript#7294:

// Before TS3.3:
declare const arr: string[] | number[];
arr.some(() => true); // error
arr.map(() => 1); // error
arr.every(() => true); // error

With TypeScript 3.3, some progress was made through microsoft/TypeScript#29011, by accepting an intersection of parameters from individual union members.

However, this enhancement only covered basic scenarios where no more than one member of the union was generic or overloaded. If the merged array methods were either generic or overloaded, they remained uncallable. Thus, there was an advancement but limitations persisted, like with map(). See microsoft/TypeScript#36390:

// TS3.3
declare const arr: string[] | number[];
arr.some(() => true); // okay
arr.map(() => 1); // error
arr.every(() => true); // okay

Subsequently, a generic overload was introduced to every() in order to serve as a type guard function; view microsoft/TypeScript#38200. Although helpful, this modification hindered every() functionality on unions of array types with the release of TypeScript 4.0:

// TS 4.0
declare const arr: string[] | number[];
arr.some(() => true); // okay
arr.map(() => 1); // error
arr.every(() => true); // error

For TypeScript 4.2+, microsoft/TypeScript#31023 addressed limited support for calling unions of generic call signatures provided the generic type parameters matched. However, challenges persist with overloaded call signatures:

// TS 4.2+
declare const arr: string[] | number[];
arr.some(() => true); // okay
arr.map(() => 1); // okay
arr.every(() => true); // error

That's our current standing.

Perhaps future updates will address microsoft/TypeScript#44373. Resolving the issue of unions of overloaded methods remains complex. There may be merit in auto-widening to a readonly-array-of-unions specifically for arrays. This manual workaround is generally safe and practical:

const arr2: readonly (string | number)[] = arr; // okay
arr2.every(() => true); // okay

Yet, it's not implemented presently.

Playground link for code exploration

Answer 2

This is a current limitation within TypeScript; reference microsoft/TypeScript#44373 for more information.

In the past, TypeScript struggled with invoking methods on a combination of array types. Initially, calling unions-of-functions was not allowed due to the challenge of merging multiple signatures into one coherent function. Check out microsoft/TypeScript#7294:

// Before TS3.3:
declare const arr: string[] | number[];
arr.some(() => true); // error
arr.map(() => 1); // error
arr.every(() => true); // error

With TypeScript 3.3, some progress was made through microsoft/TypeScript#29011, by accepting an intersection of parameters from individual union members.

However, this enhancement only covered basic scenarios where no more than one member of the union was generic or overloaded. If the merged array methods were either generic or overloaded, they remained uncallable. Thus, there was an advancement but limitations persisted, like with map(). See microsoft/TypeScript#36390:

// TS3.3
declare const arr: string[] | number[];
arr.some(() => true); // okay
arr.map(() => 1); // error
arr.every(() => true); // okay

Subsequently, a generic overload was introduced to every() in order to serve as a type guard function; view microsoft/TypeScript#38200. Although helpful, this modification hindered every() functionality on unions of array types with the release of TypeScript 4.0:

// TS 4.0
declare const arr: string[] | number[];
arr.some(() => true); // okay
arr.map(() => 1); // error
arr.every(() => true); // error

For TypeScript 4.2+, microsoft/TypeScript#31023 addressed limited support for calling unions of generic call signatures provided the generic type parameters matched. However, challenges persist with overloaded call signatures:

// TS 4.2+
declare const arr: string[] | number[];
arr.some(() => true); // okay
arr.map(() => 1); // okay
arr.every(() => true); // error

That's our current standing.

Perhaps future updates will address microsoft/TypeScript#44373. Resolving the issue of unions of overloaded methods remains complex. There may be merit in auto-widening to a readonly-array-of-unions specifically for arrays. This manual workaround is generally safe and practical:

const arr2: readonly (string | number)[] = arr; // okay
arr2.every(() => true); // okay

Yet, it's not implemented presently.

Playground link for code exploration

Answer 3

Answer №2

The reasoning behind this relates to the explanation of every()

every<S extends T>(predicate: (value: T, index: number, array: readonly T[]) => value is S, thisArg?: any): this is readonly S[];

When dealing with a union type like yours, the signature transforms into

{
  <S extends number>(predicate: (value: number, index: number, array: number[]) => value is S, thisArg?: any): true; 
  (predicate: (value: number, index: number, array: number[]) => unknown, thisArg?: any): this is S[]; 
} |
{ 
   <S extends string>(predicate: (value: string, index: number, array: string[]) => value is S, thisArg?: any): true;
    (predicate: (value: string, index: number, array: string[]) => unknown, thisArg?: any): this is S[];
}

The issue arises from the incompatible types within the predicates.

Answer 4

The reasoning behind this relates to the explanation of every()

every<S extends T>(predicate: (value: T, index: number, array: readonly T[]) => value is S, thisArg?: any): this is readonly S[];

When dealing with a union type like yours, the signature transforms into

{
  <S extends number>(predicate: (value: number, index: number, array: number[]) => value is S, thisArg?: any): true; 
  (predicate: (value: number, index: number, array: number[]) => unknown, thisArg?: any): this is S[]; 
} |
{ 
   <S extends string>(predicate: (value: string, index: number, array: string[]) => value is S, thisArg?: any): true;
    (predicate: (value: string, index: number, array: string[]) => unknown, thisArg?: any): this is S[];
}

The issue arises from the incompatible types within the predicates.

Answer 5

Answer №3

After exploring the discussion in the comments, it is evident that every includes an overload with a generic function containing a type predicate while some lacks such functionality.

What causes the current "incompatibility" of function signatures?

There seems to be a connection to their generic nature. However, a concrete answer still eludes me. Perhaps @jcalz can provide a satisfying explanation :)

Why does every possess generics and a type predicate?

In contrast to some, invoking every can impact the array's type. For instance, when you have an array like
```
const arr: (string | number)[] = []
```
Running every on it to verify if every element is a number could potentially alter the resulting array's type.
```
const arr2 = arr.every((e): e is number => typeof e === "number")
// arr2 should be number[]
```
This alteration is facilitated by using type predicates. Therefore, for type predicates to exert influence here, every must be generic. (Otherwise, the type predicate would be disregarded by every)

So how can this issue be addressed?

I propose modifying the type of input to an intersection of (number[] | string[]) and (number | string)[]. Although unconventional, this adjustment resolves the error at hand.

function doEverythingWithArray(
  input: (number[] | string[]) & (number | string)[]
): boolean {
  return input.every(i => doSomething(i));
}

The function retains its original calling behavior.

// works as before
doEverythingWithArray(["a", "b", "c"])
doEverythingWithArray(["a", "b", "c"] as string[])
doEverythingWithArray([0, 1, 2])
doEverythingWithArray([0, 1, 2] as number[])

// fails
doEverythingWithArray([0, 1, "a"])

Playground

Answer 6

After exploring the discussion in the comments, it is evident that every includes an overload with a generic function containing a type predicate while some lacks such functionality.

What causes the current "incompatibility" of function signatures?

There seems to be a connection to their generic nature. However, a concrete answer still eludes me. Perhaps @jcalz can provide a satisfying explanation :)

Why does every possess generics and a type predicate?

In contrast to some, invoking every can impact the array's type. For instance, when you have an array like
```
const arr: (string | number)[] = []
```
Running every on it to verify if every element is a number could potentially alter the resulting array's type.
```
const arr2 = arr.every((e): e is number => typeof e === "number")
// arr2 should be number[]
```
This alteration is facilitated by using type predicates. Therefore, for type predicates to exert influence here, every must be generic. (Otherwise, the type predicate would be disregarded by every)

So how can this issue be addressed?

I propose modifying the type of input to an intersection of (number[] | string[]) and (number | string)[]. Although unconventional, this adjustment resolves the error at hand.

function doEverythingWithArray(
  input: (number[] | string[]) & (number | string)[]
): boolean {
  return input.every(i => doSomething(i));
}

The function retains its original calling behavior.

// works as before
doEverythingWithArray(["a", "b", "c"])
doEverythingWithArray(["a", "b", "c"] as string[])
doEverythingWithArray([0, 1, 2])
doEverythingWithArray([0, 1, 2] as number[])

// fails
doEverythingWithArray([0, 1, "a"])

Playground

How come I am able to use array.some() but not array.every() when working with union array types?

Answer №1

Answer №2

Answer №3

Similar questions

Conditional types can be used as type guards

What is the best way to pass individual values from an array as arguments to a function?

Expanding declaration files in TypeScript to include third-party libraries

Tips for mocking a module with a slash character in its name?

Modify color - Angular Pipe

Exploring the depths of array dimensions in the C++ programming

Having trouble passing a React Router Link component into the MuiLink within the theme

Loop through each item in the collection with attributes that contain the character '@'

Generate a JSON object by extracting variables from an array

Mapping imports in TypeScript refers to the process of linking external dependencies or modules

Show information in the Activity view upon clicking

Unable to send JSON data from server to client following a successful file upload operation

Having trouble retrieving elements from combined arrays

Why does the ReactJS MaterialUI Modal fail to update properly?

Breaking up an array of objects into separate arrays based on a specific key using JavaScript

One can only iterate through the type 'HTMLCollection' by utilizing the '--downlevelIteration' flag or setting a '--target' of 'es2015' or above

The correct method to effectively type out a JSON object

What is the most efficient way to perform an inline property check and return a boolean value

Is there a method in AngularJS to compel TypeScript to generate functions instead of variables with IIFE during the compilation process with gulp-uglify?

Utilizing TypeScript to Retrieve the Parameter Types of a Method within a Composition Class