You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
the match function is the way to start defining cases for a value, but its design is limited because its reactive rather than proactive, by this i mean that you can only define cases when the value exists in the scope but there's no way to define case handling logic in a deferred and composable way
Describe the solution you'd like
I think this can be solved if there were an API that allowed for the definition of cases without having the value that will be matched against them, for example
Now we have a lazy definition of pattern matching, that can be run against any number of values in a pure way and it could also be made composable
constdigits10=digitsFlow(10)constdigitsStringFlow=flow<number|string>).compose(digitsFlow)// new method to compose flows together.with(P.string,(s)=>n.length).exhaustive()// ts is smart enough to know that the `number` case was handled exhaustively
Describe alternatives you've considered
the naive way of course would be to make heavy use of lambdas but it would be quite ugly for composability
constdigitsFlow=(n: number)=>match(n).with(P.number,(n)=>n.toString().length).exhaustive();constdigitsStringFlow=(n: string|number)=>match(n).with(P.number,=>digitsFlow)// here you'd have to manually check that all cases are handled.with(P.string,(s)=>n.length).exhaustive()
The text was updated successfully, but these errors were encountered:
Just came here to open the same issue. Besides, this way we'll get rid of a ton of runtime allocations (every callback, every array — they are all objects created at runtime and bloat GC).
Is your feature request related to a problem? Please describe.
the
match
function is the way to start defining cases for a value, but its design is limited because its reactive rather than proactive, by this i mean that you can only define cases when the value exists in the scope but there's no way to define case handling logic in a deferred and composable wayDescribe the solution you'd like
I think this can be solved if there were an API that allowed for the definition of cases without having the value that will be matched against them, for example
Now we have a lazy definition of pattern matching, that can be run against any number of values in a pure way and it could also be made composable
Describe alternatives you've considered
the naive way of course would be to make heavy use of lambdas but it would be quite ugly for composability
The text was updated successfully, but these errors were encountered: