I have a slightly different proposal: Why not allow `|> &Regex.scan(~r/foo/ &1)` directly?
The mentioned names for the 'wrapper macro that abstracts away the anonymous function application syntax' have all been names for things that already exist: - `Function.pipe_to` is confusing because using `|>` already pipes something to something else. - `Function.apply` is confusing because `Kernel.apply` already exists and its functionality sort of overlaps with it. - `Function.capture` is confusing because the `&(&1)` syntax is known as 'capture operator' or 'shorthand capture syntax'. I agree that there are many instances where it makes sense to encapsulate work in a separatly named function rather than piping through an anonymous function. However, in examples such as the mentioned one, where it is only the order of the parameters that is sub-optimal (and when we remain at the same level of abstraction(!)), I find this: | deffind_foos(string)do string |>String.upcase() |>&Regex.scan(~r/foo/,&1) end | preferable over this: | | deffind_foos(string)do string |>String.upcase() |>do_find_foos() end def do_find_foos(str) Regex.scan(~r/foo/, str) end | | --- I believe implementing this would be rather straightforward, since we only have to look at occurrences of the `&` operator inside the (top-level) macro expansion of `|>` (i.e. all magic occurs and disappears at macro expansion time). ~Marten/Qqwy -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/e19a826f-dd41-29fb-4ce0-723e1ef25374%40resilia.nl.
signature.asc
Description: OpenPGP digital signature
