Idea: Type Unpackers for Function Parameters

[fbartho]

Because of TypeScript 2.8 Conditional Types, we can now do the following:

type Param0<Func> = Func extends (a: infer T, ...args: any[]) => any
	? T
	: never;
type T0 = Param0<() => void>; // {}
type T1 = Param0<(a: number) => void>; // number
type T2 = Param0<(a: string[]) => void>; // string[]

Issue for discussion!

Questions:

• Naming scheme?
• Multiple Parameter Unpacks at the same time?

See also ReturnType<Func>

[pelotom]

Great idea! What about just one operator which returns a tuple of types?

type ParamTypes<F extends Function> =
  F extends () => any ? {} :
  F extends (p0: infer P0) => any ? [P0] :
  F extends (p0: infer P0, p1: infer P1) => any ? [P0, P1] :
  F extends (p0: infer P0, p1: infer P1, p2: infer P2) => any ? [P0, P1, P2] :
  // ...
  never;

type T0 = ParamTypes<() => void>; // {}
type T1 = ParamTypes<(a: number) => void>; // [number]
type T2 = ParamTypes<(a: string, b: boolean) => void>; // [string, boolean]

Then you can further access particular indexes as you please, e.g.

type Third = ParamTypes<typeof f>[2];

I used ParamTypes for consistency with ReturnType; I could also be convinced Parameters or Params is a good name...

[kourge]

ArgumentsType seems more consistent, in line with arguments as well as (...args: any[]).

[fbartho]

@kourge That's a great point. Consistent options:

• ArgumentsType
• ArgumentTypes
• ArgumentType (plural is implied by operator's type-tuple return?).

@pelotom Is there a performance concern re: unpacking the whole array by default? If people are mostly going to access a single parameter, maybe we should consider that?

[pelotom]

ArgumentsType seems more consistent, in line with arguments as well as (...args: any[]).

Parameters are the declared inputs of a function signature, arguments are the runtime objects passed to a function:

https://stackoverflow.com/questions/156767/whats-the-difference-between-an-argument-and-a-parameter

@pelotom Is there a performance concern re: unpacking the whole array by default? If people are mostly going to access a single parameter, maybe we should consider that?

I really doubt there's much performance difference.

[pelotom]

On second thought you may be right about performance being a concern... I agree it might be better to play it safe.

[fbartho]

@pelotm I’d be happy with N short helpers, and also providing an up-to-N batch unpacker. (With a performance warning)

Then naming wise, should it be:

• ParamN
• ParamTypeN
• ParameterN
• ParameterTypeN

(Where N is a number) or should it be something else?

How many N should we provide?

[fbartho]

(I think the final name of the short form will influence our long form name)

[pelotom]

I think I'd actually vote ParamN (what you originally had).

[fbartho]

Implemented in #24

[chocolateboy]

Is this the same as the built-in Parameters type (which doesn't have a restriction on the number of parameters)?

https://github.com/microsoft/TypeScript/blob/eca8957430bf52cfdfa2bfe03c9431682da6a558/lib/lib.es5.d.ts#L1514

If so, does it have the same limitation (only returns the first overloaded parameters)?