Re:TIL: `satisfies` is my favorite TypeScript keyword
by Defletter on Sunday November 23, 2025 @02:33AM
(#46021543)
Isn't that not necessarily out of the ordinary though? What if there's a cosmic ray that change's the value to something not expected by the exhaustive switch? Or more likely, what if an update to a dynamic library adds another value to that enum (or whatever)? What some languages do is add an implicit default case. It's what Java does, at least: https://openjdk.org/jeps/361
[ Parent
| on HN ]
Re:TIL: `satisfies` is my favorite TypeScript keyword
by jstanley on Sunday November 23, 2025 @03:39AM
(#46021819)
> What if there's a cosmic ray that change's the value to something not expected by the exhaustive switch?
I could forgive that.
The TypeScript case is more like "what if instead of checking the types we just actually don't check the types?".
Re:TIL: `satisfies` is my favorite TypeScript keyword
by tshaddox on Sunday November 23, 2025 @09:53AM
(#46023988)
This is how all static type checking works. What programming language do you have in mind that does static type checking and then also does the same type checking at runtime? And what would you expect this programming language to do at runtime if it finds an unexpected type?
Re:TIL: `satisfies` is my favorite TypeScript keyword
by RussianCow on Sunday November 23, 2025 @12:21PM
(#46025267)
I think the point is that other languages make guarantees that ensure you don't have to do any runtime checking. In TypeScript, it's far too easy (and sometimes inevitable) to override the type checker, so some poor function further down into the codebase might get a string when it expects an object, even though there are no type errors.