If I were to do something like this I’d have the syntax as something like:

1
|> foo(0, 0) # 2
|> foo(0, &_, 0) # 6
|> div(2) # 3
|> div(3) # 1
|> foo(0, 0, &_) # 4
|> (fn x -> foo(0, 0, x) end).() # 16
|> foo(&_, 0, 0) # 32

Which is valid syntax and is syntax I’ve made but I don’t use since it is not ‘standard’ anyway, plus it is not that hard to just do 1 |> (&foo(0, &1, 0)).() or so, as ugly as it is. Maybe just a helper macro to re-shuffle args or so would be cleaner or something.

Honestly, if I were to buff pipe, adding some ‘put in this place here’ would be nice, but I’d prefer something of a more monad’y composition as error handling then would become so much easier.

It is difficult to exaggerate how much discussion has been had with respect to modifying the pipe operator. The consensus response is pretty negative to such modifications, and to be honest this is a great example why.

1
|0> foo(0, 0)
|1> foo(0, 0)
|2> foo(0, 0)

This is completely indecipherable. Obviously the foo function name doesn’t help, but the whole point of the pipe operator is that there is a consistent view on what constitutes the primary noun for each function.

I think there is some confusion between readability and familiarity. Of course a construct someone is not familiar will be unreadable to most.

The trouble with this proposal is that it puts the burden on reading code even when I am familiar with the construct, the pipe operator. When I read the examples above, I need to manually unwind the operator and place the argument on where it needs to be. It prioritizes writing code over reading code and that’s a trade-off I would hardly make.

Every time I want to pipe to another argument, I write a private function and give it a decent name. No shortcuts. And the final code will read better too.

Instead of content |1> File.write!(path) I do prefer content |> to_file(path).

When I first read about a pipe that allows to pipe into an arbitrary position, I really was keen of the idea, but after a couple of years dealing with the default pipe, I started to learn to write helper functions, which make my intend much more clear, than a number that no-one ever sees on a quick read inbetween | and >. Even worse, people are so used to |> nowadays, that they will read |x> as |>! At least if they aren’t using fonts and editors that aid to differ both.

Every line has to be re-interpreted. You have to mentally move everything around to figure out what’s going where. Reading this is a matter of doing:

1 # ok this will be the first argument
|0> foo(0, 0) # last line is first argument, yay nice left to right top to bottom reading
|1> foo(0, 0) # last line is now middle argument ok so first 0 is first argument then we have the last line, and then the last 0 is the last argument.
|2> foo(0, 0) # last line is 2nd argument so the two right 0s are actually the LEFT most argument even though they're all on the right hand side.

Notice that by the end, we’re reading from right to left, inside to out, which is precisely the whole problem that the pipe was designed to eliminate! At least with foo(0, 0, foo()) I can keep reading positions as normal.

This has been discussed more times and with more posts than I can count, and while that isn’t your fault, it does mean that I just don’t have the energy to have this conversation again. For anyone considering pursuing this further please go read the other posts on this on the forum and the elixir lang core mailing list.