`satisfies` is my favorite TypeScript keyword (2024)

Post by mquander » Sun, Nov 23, 2025, 3:32 AM UTC

mckirk wrote: post #71

amake wrote: post #48

99% of my use of `satisfies` is to type-check exhaustivity in `switch` statements: type Foo = 'foo' | 'bar'; const myFoo: Foo = 'foo'; switch (myFoo) { case 'foo': // do stuff break; default: myFoo satisfies never; // Error here because 'bar' not handled }

I generally do this via a `throw UnsupportedValueError(value)`, where the exception constructor only accepts a `never`. That way I have both a compile time check as well as an error at runtime, if anything weird happens and there's an unexpected value.

Post by rezonant » Sun, Nov 23, 2025, 3:55 AM UTC

mckirk wrote: post #71

amake wrote: post #48

99% of my use of `satisfies` is to type-check exhaustivity in `switch` statements: type Foo = 'foo' | 'bar'; const myFoo: Foo = 'foo'; switch (myFoo) { case 'foo': // do stuff break; default: myFoo satisfies never; // Error here because 'bar' not handled }

I generally do this via a `throw UnsupportedValueError(value)`, where the exception constructor only accepts a `never`. That way I have both a compile time check as well as an error at runtime, if anything weird happens and there's an unexpected value.

Post by paulddraper » Sun, Nov 23, 2025, 4:28 AM UTC

epolanski wrote: post #3

> TypeScript is a wonderfully advanced language though it has an unfortunately steep learning curve An extremely steep one. The average multi-year TypeScript developer I meet can barely write a basic utility type, let alone has any general (non TypeScript related) notion of cardinality or sub typing. Hell, ask someone to write a signature for array flat, you'd be surprised how many would fail. Too many really stop at…

Post by lovich » Sun, Nov 23, 2025, 5:08 AM UTC

ffsm8 wrote: post #86

wk_end wrote: post #68

Earlier quoted context omitted.

There's nothing I can do about the standard JavaScript library, but in terms of code I have influence over, I very simply would not write a difficult-to-type method like Array.prototype.flat(), if I could help it. That's what I mean by an XY Problem - why are we writing this difficult-to-type method in the first place and what can we do instead? Let's suppose Array.prototype.flat() wasn't in the standard library, whi…

> MyStructure -> [MyElements] Right, from the structure you get an array with one element which is likely an union type from that naming. Honestly, you sound more like your arguing from the perspective of a person unwilling to learn new things, considering you couldn't even get that type correct. To begin with, that flat signature wasn't even hard to understand?

Post by what » Sun, Nov 23, 2025, 5:12 AM UTC

epolanski wrote: post #18

ForHackernews wrote: post #10

Earlier quoted context omitted.

Honestly I just use TypeScript to prevent `1 + [] == "1"` and check that functions are called with arguments. I don't care about type theory at all and the whole thing strikes me as programmers larping (poorly) as mathematicians.

I couldn't care less about mathematics, but I do care about making impossible state impossible and types documenting the domain. If you type some state as: isLoading: boolean result: Foo hasError: boolean errorMessage: string | null then you're creating a giant mess of a soup where the state of your program could have a result, be loading and an error at the same time. If you could recognise that the state of your pr…