Proposal: Kernel Module: put_ok/1 and put_error/1

[Chris]

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.

[Syed Murtza]

it's nice. A+ 

Sent from my iPhone

--
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-co...@googlegroups.com.
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.

[Andrea Leopardi]

Hey Chris,

thanks for your proposal! Personally, I'm not a fan of adding such functions. I feel they assume too much; why limit to only :ok and :error? They of course are common in Elixir/Erlang, but one may want to return {:value, something} or :no_values, or any other API that doesn't use :ok and :error. Also, it's a bit restrictive to assume that we want to return {:ok, something} instead of something like {:ok, something, something_else} (this is what your implementation in https://github.com/elixir-lang/elixir/pull/4650 assumed at least).

It's really trivial to implement such helper functions like these that can be specific to your project, so I think that's where these belong :).

Andrea

Andrea Leopardi

an.le...@gmail.com

--

[Greg Vaughn]

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

[Chris]

Agreed, and I have them in my own libraries. Thought they might be useful to others :)

[Chris]

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.

[FTS]

explicitly:

```elixir

def return_first(id_list), do: id_list |> List.first!() |> (&{:ok, &1}).()

```

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/0c1ced04-3f91-4108-859f-6a8490b3bab5%40googlegroups.com.

[Onorio Catenacci]

+1 Greg.  Totally agree.  To quote the old saw--too much of a good thing is not a good thing.

[Chris]

I guess it's a matter of preference and personal perspective. Whether you choose to express it as a series of transformations through functions, or whether you nest it into the return value. Just two different ways of thinking about the same thing.

You could similarly argue there is no need for the division operator when you could always just multiply by the reciprocal.