Idiomatic HKTs and Variadic Generic Types

[keyvan-m-sadeghi]

Suggestion

Pertaining to the discussion in #1213 and having looked at similar suggestions (borrowing ideas where appropriate), this is a strawman proposal (syntax only) on HKTs and Variadic Generic Types that adheres to existing syntax and mindset in JS/TS , hence named "idiomatic".

🔍 Search Terms

HKT Higher Order Types Higher Kinded Types Higher Order Type Functions Higher Order Function Generic Variadic Generic Types

✅ Viability Checklist

My suggestion meets these guidelines:

• [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• [x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Higher Kinded Types

Suggested syntax:

type HKT<S><T><V> = S<T<V>>;

Properties

• Positional clarity, same syntax for definition and invocation, visually similar to HOF calls: f(x)(y)(z)

  type WrappedArray<S><T> = S<T>[];
  type ArrayOfPromises<T> = WrappedArray<Promise><T>;
  // With a glance at the definition, we'll know that Promise is
  // positionally assigned to S when invoked

• Spontaneous logic: more to the left => higher the kind (again similar to HOFs)
• Omission of lower kind = implicit inclusion

  type ArrayOfAsyncIterables = WrappedArray<AsyncIterable>;
  // == type ArrayOfAsyncIterables<T> = WrappedArray<AsyncIterable><T>;

Variadic Generic Types

Suggested syntax:

function aFunction<...T>(...args) {
  return anotherFunction<...T>(...args);  
}

Properties

• Reuses spread operator, same as in Variadic Tuple Types, exact match with how parameters are spread in JS
• Paves the way for generic inference

  type Generics<F extends (...args) => any> = F extends <...infer G>(...args) => any
  ? G
  : never;

📃 Motivating Example

I was looking at the code in the streaming-iterables package, the pattern of defining an _fn and then overloading it with an fn including a curried version seems a case of DRY, happens in all functions the package exposes.

Below code was my attempt at a general currying overload implementation for the package:

type Leading<T extends any[]> = T extends [...infer I, infer _] ? I : never;
type Last<T extends any[]> = T extends [...infer _, infer I] ? I : never;

function curried<F extends (...args) => any>(
  fn: F
): {
  (...args: Parameters<F>): ReturnType<F>;
  (...args: Leading<Parameters<F>>): (curried: Last<Parameters<F>>) => ReturnType<F>;
} {
  return (...args) =>
    args.length == fn.length - 1
      ? curried => fn(...[...args, curried]) 
      : fn(...args);
}

This works well until generics come into play:

function a<T>(b: string, c: number, d: T[]) {
  return [b, c, ...d];
}

const f = curried(a);

f('hi', 42, [1, 2, 3]) // d: unknown[], expected: number[]
f('hi', 42) // curried: unknown[], expected: T[]

SO Question

💻 Use Cases

Using this proposal, the example described in the previous section can be covered:

function curried<F extends (...args) => any>(
  fn: F
): {
  <...T extends Generics<F>>(...args: Parameters<F><...T>): ReturnType<F><...T>;
  <...T extends Generics<F>>(...args: Leading<Parameters<F><...T>>):
    (curried: Last<Parameters<F><...T>>) => ReturnType<F><...T>;
} {
  return // same as before
}

[RyanCavanaugh]

This is a good start to describe some uncontroversial syntax, but doesn't go far enough to describe behavior outside of the straightforward cases, which is where 99% of the difficulty is here. It seems like this belongs more as a comment at #1213?

[keyvan-m-sadeghi]

Agreed @RyanCavanaugh. Main goal was to demo it's probably possible to introduce HKTs and Variadic Generic Types without imposing more cognitive overhead (syntaxes like <-> or ^2). I changed the intro to clarify that it's only strawman at this stage, but the issue can serve as a reference when discussing new syntaxes. Already commented in #1213.