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)?

[fbartho]

@chocolateboy I believe these are equivalent implementations. The built-in one didn't exist when we added this one, as far as I know.

As such I expect it to be subject to the same limits. But you should test it and let us know!

We don't use many overridden method definitions in our codebase, because the syntax could be confusing.