explicitly:
```elixir
def return_first(id_list), do: id_list |> List.first!() |> (&{:ok, &1}).()
```On Fri, May 20, 2016 at 6:11 AM, Chris <[email protected]> wrote: > Very simplistic. I tend to prefer functions that state a transformation of > data through a series of pipelines. My normal usecase for this is something > a bit deeper than a one function pipe. > > I've used this tuple representation a bit to good effect, but I find that > it becomes a bit unclear when my series of pipeline transformation > functions becomes too long. Starts to look a bit too much like an > anti-pattern past a few pipes. > > On Thursday, May 19, 2016 at 2:58:38 PM UTC-7, Greg Vaughn wrote: >> >> I love the pipe operator. I really do. However, I worry that some people >> are overusing it. What's wrong with this?: >> >> def return_first(id_list) do >> {:ok, List.first!(id_list)} >> end >> >> I really don't see put_ok/1 and put_error/1 being worth putting in std >> lib. I don't want to encourage over-use of the pipe operator. >> >> Granted you gave a simplistic example, but even if things were warranting >> a more complex pipeline, you can still do: >> >> def return_first(id_list) do >> { >> :ok, >> id_list |> List.first! >> } >> end >> >> with no addition to the standard library. >> >> -Greg Vaughn >> >> >> > On May 19, 2016, at 4:47 PM, Chris <[email protected]> wrote: >> > >> > These are a couple of small wrapper functions which I think would be >> very useful to developers. They create an idiomatic pathway for returning >> tuples from a pipeline. >> > >> > >> > >> > The intended use case is in any module-level function that is entirely >> a pipeline, and where you would like to return the value that is the result >> of a pipeline of functions in tuple form, and >> > where you know the result of your pipeline will be either :ok or :error >> with certainty. >> > >> > For a simplistic example, suppose I have a list of ids and I write a >> simple function to take the first id and return it in an >> > :ok tuple. Normally I would have to do something like this: >> > >> > >> > >> > def return_first(id_list) do >> > first_id = id_list |> List.first!() >> > {:ok, first_id} >> > end >> > >> > >> > >> > And that is okay, but somehow it doesn't feel like idiomatic >> > Elixir. Here you could just do this: >> > >> > >> > >> > def return_first(id_list), do: id_list |> List.first!() |> put_ok() >> > >> > >> > >> > To me, that feels a lot cleaner and clearer. It allows me to express my >> intention the in a way that feels closer to how Elixir >> > asks me to think about programming. >> > >> > >> > -- >> > 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/60d8054e-7f88-48ad-9ead-5ccc8ba1eccf%40googlegroups.com. >> >> > For more options, visit https://groups.google.com/d/optout. >> >> -- > 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/0c1ced04-3f91-4108-859f-6a8490b3bab5%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/0c1ced04-3f91-4108-859f-6a8490b3bab5%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAHsFyS894J%3DwN-217OSOm6SiL4t8zJuuu30eEya3rcsLuFwZjQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
