There is with co struct:

with {:ok, v} <- foo(), do: {:ok, v * 2}

Thanks for the reply! The with construct can help quite a bit in the case I mentioned above, but it also becomes hairy when you want to map the value associated to the :error as well. Having a function such as map_error helps a lot in such a case. There are many more combinator functions possible, which are extensively used in other programming languages with functional roots (Haskell and Rust come to mind). That is why I thought we might have them in Elixir as well (otherwise I guess I might contribute with a library ;))

The thing with these languages is that these are strongly typed, which mean that you can implement fmap or bimap functions in a way that preserve structure. In Elixir you would need to have function for each of the “types” separately. So as it would be hard to do in Elixir stdlib it is left up to the user to implement them on their own (which is fairly easy, especially when you have with construct).

Hmm… My impression is that using {:ok, something} and {:error, something_else} are so widespread, that you could easily treat them as “Elixir’s implementation of Rust’s Result and Haskell’s Either type”. But then again, I am fairly new to Elixir, so maybe there are more things to consider than I can see right now.

As far as I know Elixir does not implements any helper function to work with pipes except Kernel.tap/2 and Kernel.then/2, but those works for all type of input - not only specific one

How about writing a simple macro based on then?

defmodule Example do
  defmacro ok_then(value, fun) do
    quote do
      case unquote(value) do
        {:ok, result} -> {:ok, unquote(fun).(result)}
        result -> result
      end
    end
  end

  def divide(_x, 0), do: {:error, :zero_divisor}
  def divide(x, y), do: {:ok, div(x, y)}
end

require Example

x
|> Example.divide(y)
|> Example.ok_then(&(&1 * 6))
|> Example.ok_then(&(&1 * 7))
|> then(fn
  {:ok, result} -> IO.inspect(result, label: "Transformed result")
  {:error, :zero_divisor} -> IO.warn("Zero divisor problem …")
  {:error, error} -> IO.warn("Unexpected error #{error}")
end)

Using this you can work only on data you are interested and optionally if something fails you can handle all errors in one place.

Thanks for the suggestion. A somewhat unrelated question: why use a macro instead of a function for ok_then?

There is no strict requirement that :ok or :error will be:

• tuple
• with exactly 2 elements

There is plenty of examples where that do not apply:

• GenServer.start_link/3 can also return :ignore
• Code.fetch_docs/1 returns :docs_v1-tuple or :error tuple
• IO.binread/2 can return iodata() on success, unary :error-tuple on error or :eof

Examples like that can be written and written, especially when you add Erlang libraries to the mix. It is hard to have “one catch them all” solution.

I would like to know as well, as functions fits much better there.

If you’re mapping the value in the error side as well, use the case you started with.

Honestly? I don’t remember.

I know that I read about it somewhere. I wrote the code after looking at then/2 macro code. I guess it was something about compile-time optimization like the macro is translated to case at compile time. I tried to find a guide describing it.