So I have a ~>/3 operator in scope and am trying to pipe in to it like:

a
|> (b ~> c)

And this works just fine if I build the AST manually (like via {:~>, [], [a, b, c]}) or call it directly (like via Blah.~>(1, 2, 3)), but I keep getting errors like this:

** (ArgumentError) cannot pipe a into 1 ~> 2, the :~> operator can only take two arguments

Which is of course a bit of hogwash since that function/operator can take 3 arguments just fine. Not even using any macro work or anything of the sort in relation to it, just standard function naming since function names can be anything, and the normal built-in pipe operator.

This seems to be an issue with lots of operator-like function names.

This is trivially replicatable via a minimal case like:

iex(1)> defmodule Blah do
...(1)>   def unquote(:~>)(a, b, c), do: a+b+c 
...(1)> end
{:module, Blah,
 <<70, 79, 82, 49, 0, 0, 4, 120, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 123,
   0, 0, 0, 14, 11, 69, 108, 105, 120, 105, 114, 46, 66, 108, 97, 104, 8, 95,
   95, 105, 110, 102, 111, 95, 95, 7, 99, ...>>, {:~>, 3}}
iex(2)> 
nil
iex(3)> defmodule BlahTest do
...(3)>   import Blah
...(3)>   def test() do
...(3)>     1
...(3)>     |> (2 ~> 3) # Purely example data
...(3)>   end
...(3)> end
** (ArgumentError) cannot pipe 1 into 2 ~> 3, the :~> operator can only take two arguments
    (elixir) lib/macro.ex:155: Macro.pipe/3 
    (stdlib) lists.erl:1263: :lists.foldl/3
    (elixir) expanding macro: Kernel.|>/2
    iex:7: BlahTest.test/0

It works fine as well if I prefix the module name on it:

defmodule BlahTest do
  import Blah
  def test() do
    1
    |> Blah.~>(2, 3)
  end
end

It just fails if I try to use it directly, like via importing it, which is super weird since operators are just 2-arity functions of special names, but using those names with other arities works just fine otherwise in every-single-case that I can find except for with pipes.

As far as I can see in the code this is an explicit test and failure on the specific ‘operator’ names, but no test on if the operator actually exist with the given higher arity first (it’s just assuming that it doesn’t exist…), but I have no clue why it’s there (no comments as to the reasoning in the source…), this language inconsistency is breaking a DSEL I was trying to build for some math stuff…