trav
@techsavvytravvy
sr software engineer @ crunchyroll 🦀🔪 @ crablang winning the fight against Big Outside™
this weekend i'll be joining some friends to stream episode 1 of a brand new d&d campaign called Glow in the Dark - it's an original story created by my best friend and dm with fantasy, scifi, and anime/manga influences. come hang out sunday @ 4pm ET! twitch.tv/ptmhshow
no the function would return true, causing it to incorrectly be of type 'number' after narrowing with if statement
no because it is narrowing it down to the type and only the specified type or the FAIL unique symbol can be returned, otherwise you'll get an error you could of course return some literal value matching the type but that would have to be pretty deliberate
don't even need the deepEquals since the type will be narrowed by returning the FAIL symbol. so if it's not that, it should be our type
i will say, there are some downsides. deepEqual can obviously get expensive if you're comparing a lot of big objects, and there are some dumb things about narrowing that mean you can't return the input directly
the initial attempt is fine, but throwing then doing try/catch for each check isn't ideal and the predicate will be inferred for whatever type you return. instead i want the type param to be used explicitly and we'll return a symbol to indicate failure instead of throwing i think it's pretty nice!
so today @shreyascodes.tech had the idea to create an abstraction for predicate functions, and this is what i came up with initially. it works
so one of things you can do in typescript is create type predicates that allow you to check if an input value is a specific type with return type `x is Foo`. unfortunately there is nothing that helps you make sure the predicate is accurate - as long as it returns a boolean it will pass
really? i find that usually when it comes to i/o and async ops that my python requires more ceremony and is harder to follow than the equivalent js
oh it's nothing special just a wrapper around the defaults. can be overridden
ehhh not really, just that a function is dynamically passed to the parent as an argument
really like this pattern where the type name is also the namespace name bc i don't have to do something like Result.Result that i see some others do with the `import * as Result` thing tree-shaking could be a concern tho idk
i always forget you can scope types in typescript just like you can scope variables