I'll drop this here, sometimes dealing with options and results can indeed make the code a little bit messy but there's no way out of it, demystifyfp.gitbook.io/fstoolkit-e... has helped me in that front because I don't seem to need to create a bunch of helpers (like the tuple module) to deal with nested things, I can keep using usual constructs like let! value = anotherOption()
Also, I liked what you preferred to commit I think I'd be far mor familiar with that style than point free
Keep the posts coming I love to see F# here from time to time!
Thanks for the response. I appreciate your F# posts too!
Custom (including via library) CEs can be good for some workflows. Probably not a popular opinion, but I tend to avoid them. They have some common tripping hazards for new devs. Although more verbose, there is hardly anything clearer than match statements. There are some common refactorings to learn from them too.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'll drop this here, sometimes dealing with options and results can indeed make the code a little bit messy but there's no way out of it, demystifyfp.gitbook.io/fstoolkit-e... has helped me in that front because I don't seem to need to create a bunch of helpers (like the tuple module) to deal with nested things, I can keep using usual constructs like
let! value = anotherOption()Also, I liked what you preferred to commit I think I'd be far mor familiar with that style than point free
Keep the posts coming I love to see F# here from time to time!
Thanks for the response. I appreciate your F# posts too!
Custom (including via library) CEs can be good for some workflows. Probably not a popular opinion, but I tend to avoid them. They have some common tripping hazards for new devs. Although more verbose, there is hardly anything clearer than match statements. There are some common refactorings to learn from them too.