> > Sorry to dredge up an old thread but I wanted to push back against this > again. The point of the pipe operator is to be able to clearly express the > flow of data through a transformation. Claiming the pipe operator shouldn't > be able to handle captured or anonymous functions because it confuses how > it works is confusing an implementation detail of how the pipe operator > macro works now to how it is semantically expected to behave. Having to > wrap them in parenthesis and an invocation introduces a great deal of noise > to what could be an extremely simple syntax. As Wojtek Mach showed, it's > fairly easy to get the pipe operator to handle these cases, especially > since you're pattern matching against them anyway to give error messages. > Why pattern match only to give an error when it's easy and straightforward > to just make it work, what else could a user intend other than to call the > function?. There's a pull request here I made than extends his work so that > captured functions and anonymous functions both work. > https://github.com/wojtekmach/pipe_capture/pull/1 > "Hello" |> fn x -> IO.puts x end |> &IO.puts/1 |> &IO.puts(:stderr, &1)
vs "Hello" |> (fn x -> IO.puts x; x end).() |> (&IO.puts/1).() |> (&IO.puts(:stderr, &1)).() It seems weird to me that the pipe macro works exclusively on already invoked functions and doesn't know what to do with a function reference. -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/b2182e21-939e-4762-b603-9cd492e1650b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
