@darrylyeo GADTs in Typescript in action. Not really the best example because I'm not using recursive, but a good example. It slightly increases the codebase, but it moves business logic into the type system. By using them with the case statements below, it forces the developer to be explicit about the state of the code, and handle each possible state.

/frontend dev・founder/decentralized data wrangler /blockhead・UI/UX abstractionist・DeFi/web3 builder・dropout・24・prev /dydx, ritual.net・x.com/darryl__yeo

@darrylyeo GADTs in Typescript in action. Not really the best example because I'm not using recursive, but a good example. It slightly increases the codebase, but it moves business logic into the type system. By using them with the case statements below, it forces the developer to be explicit about the state of the code, and handle each possible state.

https://github.com/enviodev/velodrome-indexer/pull/287/files#diff-b5265cb45df3c9b118cf42de25e3f34b3b838c88120cd40d41c36ca2c9293d29R177-R214

Well, okay then!

Turns out the next version of TypeScript will fix the exact issue I ran into.

@typeof.eth, guess I won’t be needing your function overloading workaround after all. 🎉

https://youtu.be/lUl6gtytG64

Love it! GADTs are absolutely the way to go and will only get easier to use now that TypeScript 5.8 can narrow them directly off of JavaScript control flow.

Love it! GADTs are absolutely the way to go and will only get easier to use now that TypeScript 5.8 can narrow them directly off of JavaScript control flow.

https://warpcast.com/darrylyeo/0xde3a8327

Yeah, dead control flow branches could still be much smarter. Considering they’re still actively updating the type narrowing engine I think all of these annoyances will be solved eventually.

So there are a few things that are annoying. There really aren't implicit type guards that force you to handle all the types. In the switch statement, you have to add that weird default case with a "never" type, and inhabit that type in that codeblock.

The point is if you create a new type, and the case statement can reach that default case, the codeblock will error at compile. What I really want is a method dispatch to do this at the function definition level and not with weird switch/case statements.