owainlewis

(**** ML Programs from Chapter 9 of

  ML for the Working Programmer, 2nd edition
  by Lawrence C. Paulson, Computer Laboratory, University of Cambridge.
  (Cambridge University Press, 1996)

Copyright (C) 1996 by Cambridge University Press.
Permission to copy without fee is granted provided that this copyright
notice and the DISCLAIMER OF WARRANTY are included in any copy.

joshcox

// Get the type of the first argument of a function
type ArgumentType<T> = T extends (a: infer U) => any ? U : any;

// Get the head type from a tuple of types
type Head<T extends any[]> = T extends [infer H, ...any[]] ? H : never;

// Get the tail type from a tuple of types
type Tail<T extends any[]> = ((...t: T) => void) extends ((h: any, ...rest: infer R) => void) ? R : never;

// Get the Last type from a tuple of types

getify

I am often asked why I don't like a tool like TS (or Flow), and by implication, if I don't like it, the assumption is that I don't want any type aware tooling. That's not true, though.

I have many ideas for what I think type-aware tooling in JS could/should be, and they just happen to diverge significantly enough from TS/Flow that I can't bend into pretzels to fit into that mold.

Instead, I've worked on designing a tool I call TypL that I think addresses my concerns. It's in progress.

Here's my main list of motivations for designing TypL instead of TS/Flow:

1. I want a system that has both compile-time checking AND run-time checking. TypL's design is to compile away the stuff that it checks at compile time and can verify, and leave in the stuff that it knows needs run-time checking. That way, you don't have to write different sorts of type checking for compile-time and run-time. You get both from one set of typing annotation. It doesn't really seem tha