Match on the end of a pipe (Matchpipe?)

There are all kinds of useful libraries and patterns, but if you want to stick with stock Elixir then I would do (and do) this:

def some_function(start) do
  start
  |> Enum.map(&do_something/1)
  |> Enum.filter(&but_without_these/1)
  |> case do result ->
    {:ok, result}
  end
end

I use that |> case do result -> ... end pattern a lot. I know that not everyone likes it but I find it significantly more readable then misplaced variable definitions. Now if only we had proper monad’y do blocks without a library. ^.^;

If we’re talking about the specific problem of wrapping in an :ok/:error tuple I actually have a little helper that I find quite useful in my code.

defmodule MyApp.Utils do
  def wrap_in_ok(input), do: {:ok, input}
end

Using that changes the sample code to just:

def some_function(start) do
    start
    |> Enum.map(&do_something/1)
    |> Enum.filter(&but_without_these/1)
    |> MyApp.Utils.wrap_in_ok()
end

Of course this is ignoring @sebsel’s larger point about defining new bindings at the end of pipelines. For that I would think that stylistically that might mean that your pipeline/function is too long and might benefit by moving the whole pipeline into a new function. Of course the correct approach depends on the concrete problem at hand.

For non-kernel things I use the Exceptional library most often, so with it then it would be:

def some_function(start) do
  start
  |> Enum.map(&do_something/1)
  |> Enum.filter(&but_without_these/1)
  |> to_tagged_status()
end

But the case way is useful for ‘generic’ handling of the value without needing to make a new function (which you should always do, but I generally don’t if it’s only a line or two in size and just use the case instead).

EDIT: For note, to_tagged_status/1 is a lot more than just an &{:ok, &1}.() wrapper, it returns either an :ok or :error tuple depending on the value. If the value is an exception then it wraps it’s exception message in the :error tuple. If it’s already an error or ok tuple then it passes it through unchanged.

iex(devserver2@127.0.0.1)9> 42 |> to_tagged_status()
{:ok, 42}
iex(devserver2@127.0.0.1)10> nil |> to_tagged_status()
{:ok, nil}
iex(devserver2@127.0.0.1)11> {:ok, :blah} |> to_tagged_status()
{:ok, :blah}
iex(devserver2@127.0.0.1)12> Enum.OutOfBoundsError.exception("error message") |> to_tagged_status()
{:error, "error message"}
iex(devserver2@127.0.0.1)13> {:error, :blorp} |> to_tagged_status()
{:error, :blorp}

I quite like the style of returning ok/error tuples, raw ok values, or exceptions. It is quite useful I’ve found.

I realize I am really just asking for a “reversed match operator” (so it should contain a =), and this is it’s primary use-case, but there could be others.

a = 1
2 - 1 |= ^a

start
|> some_function()
|= result

The downside to such an operator would be that it’s yet another thing to learn, and that the error ‘no match of right hand value’ becomes cryptic (for it’s now the left hand value).

I was aware that there are other solutions, but I like piping into a case for this! It gives a nice reminder that if you make a specific match, you should add a branch for when it does not match.

Yeah, I could have made my example harder, because that was not my point. I would like to actually see the tuple in the function tho, that reads faster

I created this pull-request to a lib I have: Creating match macro by kelvinst · Pull Request #1 · kelvinst/plumbing · GitHub

Basically introducing a match macro, that you could use like:

import Plumbing

1
|> Kernel.+(2)
|> match(a)

match(%{x: 3}, %{x: ^a})

I tried the |= operator, but elixir syntactic parser does not allow it. And at the end, I like the “functiony” look of match

Oh, nice. There is already a match?(a, b), which returns a boolean, but that one also matches right to left, which can be confusing.

Cool, I also use it a lot and was wondering if it was considered a “bad” (as in unreadable) style.

Some, including me, do consider it rather unreadable . I’d much rather see:

result =
  start
  |> Enum.map(&do_something/1)
  |> Enum.filter(&but_without_these/1)

{:ok, result}

or even

{:ok,
 start
 |> Enum.map(&do_something/1)
 |> Enum.filter(&but_without_these/1)}

But the case do does not define a result variable usable afterwards. It is not equivalent to the proposed syntax, no ?

Yes, @sebsel 's reversed match operator |= is semantically different than piping a case do, but they are similar in some situations.

The “problem” is that sometimes I need to further process some internal element, like:

start
|> Enum.map ...
|> Enum.reduce ...
|> case do {x, y} -> {Enum.reverse(x), y} end
|> foo