To reduce the amount of function splits and these micro-functions, I use a helper function called validate, which transforms a boolean into :ok | {:error, reason}:

def validate(true, _reason), do: :ok
def validate(false, reason), do: {:error, reason}

And now you can write

with :ok <- validate(User.exists?(updated_user.id), :not_found), ...

It doesn’t solve all the problems you mention, but it can often help avoiding micro-functions and keep the logic in a single place, for the price of a small function whose semantics are easy to grasp. I’ve introduced it to multiple teams and programmers with different experience levels, and it worked quite well, especially in combination with Repo.transact mentioned in another thread.

I think you all are being too harsh on OP here, he spotted a problem and offered his take on it. Let the guy live, he doesn’t deserve the death sentence you are giving him.

@ImNotAVirus I do understand the motivation for your library but I’d be personally against using it in its current form because to me it introduces ambiguity and conditions in pipes, and overall just increases code size without offering clarity of intent in return. Furthermore, the problem statement is to me minor; I never found it problematic to have my guard up and properly catch singular :ok / :error atoms. It’s part of the job, plus we have Dialyzer, plus we have “Go to definition” and “Go back” in our IDEs, so… I don’t know. The problem does not seem major to me.

IMO if you want to push the library ahead then you should aim for ultra mega hyper terseness; not just the to_result renaming that you said you’ll adopt, but also you should have only 2-3 functions in the library that do practically everything that your current separate functions are doing right now.

My points:

• You want to call functions that are not guaranteed to return proper {:ok, value} / {:error, reason} tuples? Use a singular library function e.g. ok_err (or to_result) that absolutely always will return the proper tuple regardless of what is fed to it.

• You want to have custom validation / error reporting functionality? Well, IMO that is another library. Your post (and likely the library as well) seems to be mixing concerns.

• The Elixir community usually resists usage of such libraries because (a) most teams feel that doing what the library does is trivial enough and (b) nobody wants to adopt new idioms without a very clear value proposition.

Another solution is to use your editor to inspect the function (hover, keyboard shortcut, etc) to see the spec. This doesn’t introduce cognitive load, you learn the standard library, you don’t pay a performance penalty and are more likely to write idiomatic code.

It is convention that functions/macros ending with a ! raise exceptions.

I echo some sentiments here. There is reason behind different return value types. Possibly not in some libraries and certainly within private projects, but there is certainly good reason for the choice of all return types. For example there is no point in returning a 2-tuple for the happy path if we’re not passing back any other data. ok/error tuples are used as light-weight exceptions and only when the caller can do something about it (talked about here). Ecto.Repo.get/2 returns nil so it can be used in a scenario where the record might not exist. When you use this function, you are communicating to the reader that there are scenarios where the record won’t exist, but it’s not an “error” and doesn’t need any kind of messaging. Ecto.Repo.create/1 returns an ok/error tuple because something can go wrong at the database level which usually happens because the user made an error. Finally Ecto.Repo.get!/2 raises and is used when we know for a fact the data exists and if it doesn’t, there is nothing we can do about it other than Let it Crash™ or, if that doesn’t work, stay late on a Friday to fix it.

Don’t worry, I can take criticism. I’m well aware that this library is a very personal point of view. Honestly, I didn’t expect anyone to use it when I published it. I just wanted to share it because I wish I’d had it years ago, so I’m thinking it might be useful to someone one day.

The personal point is, before discovering with which was recent and not necessarily widespread when I started Elixir, I had come across this article when it first came out which talked about Railway Oriented Programming.

I was immediately hooked on the design and then had a hard time switching to with a few months later when I learned of its existence. At the time, and still very often today, I found its syntax rather complicated to read, even more so when the pattern match types are different and even more when you have to process them in the else.

In my opinion, one of the disadvantages of ROP is that where with is verbose in the function that makes the pattern matching, ROP deports this verbosity to the functions called.

I’ve been doing Elixir for several years now, and it’s almost the only language I’ve touched in a long time. I’ve hardly ever done Rust in my life.

So how did this library come about?
I was developing a feature for work where I needed to make a kind of validation pipeline for some data. I first wrote it with a with as usual, but I didn’t like the result. Then I rethought about ROP (I hadn’t done one for several years now). So I rewrote the functionality and asked my colleagues whether they preferred the version with a with or the ROP version.
One of my colleagues gave me a very interesting thought when he told me that what I wanted to do was similar to what Rust and its Results offered. So I took a look at the API and, as with the ROP, I was immediately hooked. So I rewrote the API as Elixir.

So I’m like a lot of you guys. I’ve been doing Elixir for several years now, I’ve hardly ever done Rust but yet this API suits me just fine. This is the design choice I’ve made, and from my point of view, I find it more appropriate than with in some cases. But I don’t expect you to do the same.

This article explains my point of view quite well too: Chris Bailey · Elixir's `with` statement and Railway Oriented Programming