Heh, I link your ‘ok’ library at times as an example of doing things. For context there are other libraries for this style of piping and with style error handling. There is happy (my personal favorite for the general case, entirely replaces with via happy_path, but with extra features like a default else case for things not handled in the main else area and such, and works on older Elixir’s), ok_jose, which is kind of like your “ok” except instead of adding a new inline operator it uses the normal pipe operator, you just have to finish your pipeline with |> ok, which thanks to how it compiles all the entire previous pipeline gets passed in to ok as a macro to do its work, and lastly the new-comer (just released) exceptional, which has 3 different ways of error handling, the usual tagged tuples like ok/ok_jose/happy/with support for error handling, exceptional handling, and a new method of returning the wanted value or returning an exception object (not raising it, returning it) to handle the successful/error cases, an interesting looking style I need to look closer at.
Now I barely use with itself because I use the default else case of happy_path/happy_path! excessively (great for handling generic errors in phoenix like bad params, bad database lookup, etc… etc…), but considering happy_path and with do the same kind of use-case in an almost identical way then I do not really ever use things like ok/ok_jose/etc but instead I do pattern match out the tuple, this is because I have my default error case handle almost everything (case-specific things are handled via a case branch, that then falls back to the generic error handler) and returning a message saying the user passed a bad argument or there is no row with that ID or whatever is a nicer message.
