What is the reason for Parameters<Func> not being able to extend unknown[] (Array<unknown>) in TypeScript strict mode?

Question

What is the reason for Parameters<Func> not being able to extend unknown[] (Array<unknown>) in TypeScript strict mode?

The main point of the title is that I have come across this particular code:

  type testNoArgsF = () => number;
  type testArgsF = (arg1: boolean, arg2: string) => number;
  type unknownArgsF = (...args: unknown[]) => number;
  type anyArgsF = (...args: any[]) => number;

  type testII = testArgsF extends anyArgsF ? true : false; // true
  type testIII = Parameters<testArgsF> extends Parameters<unknownArgsF>
    ? true
    : false; // true

  // surprising:
  type testIV = testArgsF extends unknownArgsF ? true : false; // false <- why?
  // but:
  type testV = testNoArgsF extends unknownArgsF ? true : false; // true

This piece of code is specifically in typescript (version 3.8), with strict mode enabled. What perplexes me is why a test function does not extend a function type with spread args of unknown[], even though their parameters do indeed extend unknown[]. Given that the return type always remains as number, I am unsure about what other factor might be causing the extends statement to turn out false.

Here are some additional observations:

The extend statement holds true only if your test function has zero arguments.
This unique behavior vanishes when you disable strict mode.

typescript types arguments extends spread-syntax

Answer 1

Answer №1

When you enable the --strictFunctionTypes compiler option, function type parameters are checked in a contravariant manner. Contravariant means that the subtype relationship of the function changes in the opposite direction compared to that of function parameters. Therefore, if A extends B, then

(x: B)=>void extends (x: A)=>void

is true rather than vice versa.

This poses a type safety issue due to the concept of "substitutability" in TypeScript, also referred to as behavioral subtyping. If A extends B is valid, you should be able to use an instance of A where a B is expected. Otherwise, the claim that A extends B is incorrect.

Disabling the --strict flag reverts the compiler to pre-TS-2.6 behavior of checking function parameters bivariantly, which although allowed for productivity reasons, is unsafe. For further details on this specific behavior, refer to the TypeScript FAQ entry on "Why are function parameters bivariant?"

In scenarios where you require a function type capable of accepting any number of unknown parameters, it's risky to restrict the usage to only a specific subtype of unknown. The following example illustrates this:

const t: testArgsF = (b, s) => (b ? s.trim() : s).length
const u: unknownArgsF = t; // error!

u(1, 2, 3); // results in runtime issues! s.trim is not defined

If testArgsF extends unknownArgsF were indeed true, the assignment of t to u above would cause runtime errors when u accepts a non-string second argument. It highlights the importance of ensuring the subtype or implementation of a function type allows arguments that are equal or wider than those anticipated by the super type or call signature, hence why --strictFunctionTypes was introduced.

...

Alright, I hope this explanation proves helpful. Best of luck!

Playground link to code

Answer 2

When you enable the --strictFunctionTypes compiler option, function type parameters are checked in a contravariant manner. Contravariant means that the subtype relationship of the function changes in the opposite direction compared to that of function parameters. Therefore, if A extends B, then

(x: B)=>void extends (x: A)=>void

is true rather than vice versa.

This poses a type safety issue due to the concept of "substitutability" in TypeScript, also referred to as behavioral subtyping. If A extends B is valid, you should be able to use an instance of A where a B is expected. Otherwise, the claim that A extends B is incorrect.

Disabling the --strict flag reverts the compiler to pre-TS-2.6 behavior of checking function parameters bivariantly, which although allowed for productivity reasons, is unsafe. For further details on this specific behavior, refer to the TypeScript FAQ entry on "Why are function parameters bivariant?"

In scenarios where you require a function type capable of accepting any number of unknown parameters, it's risky to restrict the usage to only a specific subtype of unknown. The following example illustrates this:

const t: testArgsF = (b, s) => (b ? s.trim() : s).length
const u: unknownArgsF = t; // error!

u(1, 2, 3); // results in runtime issues! s.trim is not defined

If testArgsF extends unknownArgsF were indeed true, the assignment of t to u above would cause runtime errors when u accepts a non-string second argument. It highlights the importance of ensuring the subtype or implementation of a function type allows arguments that are equal or wider than those anticipated by the super type or call signature, hence why --strictFunctionTypes was introduced.

...

Alright, I hope this explanation proves helpful. Best of luck!

Playground link to code

Answer 3

Answer №2

Let's simplify it: "extends" means "compatible" which translates to "can be used in place of."

Could you utilize

(arg1: boolean, arg2: string) => number;

in lieu of

(...args: unknown[]) => number

?

No, because the latter can work with calls without arguments, but the former may fail during runtime (for example, trying to access properties of the arguments).

For more information on function compatibility, visit this link

Answer 4

Let's simplify it: "extends" means "compatible" which translates to "can be used in place of."

Could you utilize

(arg1: boolean, arg2: string) => number;

in lieu of

(...args: unknown[]) => number

?

No, because the latter can work with calls without arguments, but the former may fail during runtime (for example, trying to access properties of the arguments).

For more information on function compatibility, visit this link

Answer 5

Answer №3

type testIV = testArgsF extends unknownArgsF ? true : false; // false 
type testIVa = unknownArgsF extends testArgsF  ? true : false; // true!

// because
type testIII = Parameters<testArgsF> extends Parameters<unknownArgsF>
    ? true
    : false; // true

Extends essentially signifies 'is assignable to'. And f(p:A)=> is assignable to f(p:B)=> if B is assignable to A. This concept is known as 'contravariant'.

// Consider a scenario where your function expects a callback with certain parameter types:

var f = (cb: ({ a, b }: { a: number, b: number }) => void) => { cb({ a:1, b: 1}); };

// you can safely call it by providing a function that accepts parameters
// which are assignable to the original parameters, but not vice versa
// this ensures that when our function f calls the callback,
// it will have sufficient data to work with
f(({ a }: { a: number }) => { })


var x = { a: 1, b: 1 };
var y = { a: 1 }

x = y; // results in error as x would lose its b property post assignment
y = x; // works fine since y has all necessary properties after assignment, it doesn't matter if it also has property b

// in simpler terms:
type F = { a: number } extends { a: number, b: number } ? true : false; // false
type T = { a: number, b: number } extends { a: number } ? true : false; // true

// interpret 'extends' as 'is assignable to'

Answer 6

type testIV = testArgsF extends unknownArgsF ? true : false; // false 
type testIVa = unknownArgsF extends testArgsF  ? true : false; // true!

// because
type testIII = Parameters<testArgsF> extends Parameters<unknownArgsF>
    ? true
    : false; // true

Extends essentially signifies 'is assignable to'. And f(p:A)=> is assignable to f(p:B)=> if B is assignable to A. This concept is known as 'contravariant'.

// Consider a scenario where your function expects a callback with certain parameter types:

var f = (cb: ({ a, b }: { a: number, b: number }) => void) => { cb({ a:1, b: 1}); };

// you can safely call it by providing a function that accepts parameters
// which are assignable to the original parameters, but not vice versa
// this ensures that when our function f calls the callback,
// it will have sufficient data to work with
f(({ a }: { a: number }) => { })


var x = { a: 1, b: 1 };
var y = { a: 1 }

x = y; // results in error as x would lose its b property post assignment
y = x; // works fine since y has all necessary properties after assignment, it doesn't matter if it also has property b

// in simpler terms:
type F = { a: number } extends { a: number, b: number } ? true : false; // false
type T = { a: number, b: number } extends { a: number } ? true : false; // true

// interpret 'extends' as 'is assignable to'

What is the reason for Parameters<Func> not being able to extend unknown[] (Array<unknown>) in TypeScript strict mode?

Answer №1

Answer №2

Answer №3

Similar questions

Tips for incorporating a mesh into Forge Viewer v6 with Typescript

Tips for showing nested JSON data in a PrimeNG table within Angular version 7

What is the best way to combine various express routes from separate files in a TypeScript project?

Exploring the differences between Office Fabric UI's I[component]StyleProp and the I[component]Styles interface

An issue has occurred: the property 'map' cannot be read as it is undefined

What is the method for comparing fields within an input type in type graphql with the assistance of class validator decorators?

Discover the seamless transformation of a class definition into a Vue 3 component definition utilizing the dazzling 'tc39' decorators

Enhancing Your React Code with Prettier, ESLint, and React

What are the steps to integrate webpack with .NET 6?

react Concealing the Card upon clicking a different location

The Material UI Grid is not compatible with the Chrome DevTools Device Toolbar and may not function properly

Troubleshooting: Difficulty assigning a value to a nested object in Angular

Is React Typescript compatible with Internet Explorer 11?

After refreshing the page, RouterLinkActive in Angular 6 fails to work

Generating a dynamic optional parameter for deduced generics

Leverage the exported data from Highcharts Editor to create a fresh React chart

What are the steps to resolving an issue in a Jest unit test?

Creating a Redis client in Typescript using the `redis.createClient()` function

Calling the `firstValueFrom()` method in RxJS will keep the observable alive and not

Utilizing the functionalities provided by node.js, I came across an issue and sought out a solution for the error message "TypeError: __WEBPACK_IMPORTED_MODULE_3_fs__.writeFile is not a function"