Michael Rutter

Well under the original `otherwise` API it never gave the original value in the first place. It was added because of an ergonomic concern around unbound values coming from function...

In case you are interested in the recent history of exhaustive: https://github.com/gvergnaud/ts-pattern/issues/16

Your use case is completely valid in terms of wanting to be forwards compatible with upstream API changes. I'm not a maintainer so I don't get much say. I personally...

@jerelmiller goodness forgot that I made this feature request. Yes, at the time I wrote this I didn't really appreciate the normalised nature of the cache and the complexity it...

I think its been like this for a little while. I'm trying to figure out what is wrong with `FieldAttributes`, but essentially `component`, `render`, and `children` are all failing to...

In fact the entire `Field` prop type is: `any`

Part of the problem is that `Field` takes `FieldAttributes` as its prop type, but `FieldAttributes` includes the intersection `& T`, which means that FieldAttributes gets cast to `any`. However, even...

In some cases it can be hard to create an API that is both type safe and easy to use. We probably need some kind of patch pushed because now...

```ts type As = "input" | "select" | "textarea"; type GenericFieldHTMLAttributes< T extends As | undefined = undefined > = T extends undefined ? JSX.IntrinsicElements["input"] & JSX.IntrinsicElements["select"] & JSX.IntrinsicElements["textarea"] :...

The order of the intersections does not matter. All intersections that include `any` are `any`: ```ts type Foo = number & any; // any type Bar = any & number;...