Tom Crockett

> Also allocating [,,] might be a red flag for mobile games or other perf critical applications. I'm fairly certain the allocation of an extra array to hold a subset...

> But my approach to perf is, "measure first, then optimize". I should clarify, that rule only applies to optimizations that don't change asymptotic complexity. For issues like the one...

> ```typescript > case surface = match(shape, [ > [Rectangle, ({height, width})=> height * width], > [Circle, ({rad})=> Math.PI * rad * rad], > ]); > ``` > > What...

> I guess I can see value in being able to define the union being operated on at the top level, and then have the cases progressively whittle away away...

FYI I've got a [work in progress PR](https://github.com/pelotom/runtypes/pull/37) for parallel pattern matching, which should address the main performance problem you brought up.

The static `.exhaustive()` check technique is very cool, @gcanti! And your original example drives home that this type of API can be quite general; all it needs is type guards,...

I'm a little bit reluctant to make the change you're proposing because it doubles the size of the already enormous match signatures, thereby compounding the difficulty of adding new overloads...

I filed an issue with TypeScript about this: https://github.com/Microsoft/TypeScript/issues/23312 It appears that this would work fine if we were using arrays instead of varargs for the case arguments.

I'm not sure, worth a try?

It was added to support third party integrations; see #16 and #17. Typical users probably don't need to know about it, but the documentation could certainly say something to that...