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.