I like ... honestly. & is already overloaded, so sometimes I worry about adding new meanings. ... is relatively safe, doesn’t cause precedence issues, and is unlikely to be used as a variable.

I’m very eager to see how this will develop. CapturePipe has two disadvantages, both related to the fact that & is already used in a somewhat different way in existing code:

• There are some theoretical edge cases in which it could have surprising results. Essentially, when someone puts a pipe inside a capture, this is always turned inside-out by CapturePipe (because that’s how it works) and in certain cases this might lead to unexpected behaviour.
• The formatter formats the original source code and has no clue that & will be shuffled around, so it will very much clobber the pipelines that contain it.

Magritte has neither of these disadvantages. I personally do not like using ... as chosen ‘fill in’ argument that much because it is used in many other programming languages to stand for multiple (e.g. variadic) arguments. I’d definitely be a proponent of using &_. This still does need some thought (unless a new dedicated token is added to Elixir for it) because while foo(1, &_, 3) works fine, &_ + 2 will be parsed as if it was the (nonsensical) capture &(_ + 2). Maybe there is a way to deal with this gracefully, I don’t know at this time.

Or function:

defmodule Foo do
   defp ..., do: IO.puts("Hello there")

  def run do
    ...
    IO.puts("General Kenobi")
  end
end

... could be a variable !?

Nice work. It might be obvious to others, but you may wish to add in the docs that you need to use Magritte not import Magritte.