If the choice is between:
value |> Tuple.wrap() |> Tuple.insert_at(0, :ok)
and
{:ok, value}
I believe we should choose the second every time.
If the choice is between:
value
|> very()
|> long()
|> pipeline()
|> Tuple.wrap()
|> Tuple.insert_at(0, :ok)
and:
value
|> very()
|> long()
|> pipeline()
|> OkError.ok()
and:
var =
value
|> very()
|> long()
|> pipeline()
{:ok, var}
I don't see any reason why we should ever do the first one.
So I really don't see which problem Tuple.wrap is supposed to solve.
*José Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R&D
On Wed, Apr 17, 2019 at 12:58 AM <t...@scalpel.com> wrote:
> I understand that this is possible, and thank you for the suggestion but
> I'm not the biggest fan of anonymous functions.
>
> When I go back and read programs written this way I can't tell if I wrote
> the code or a cat walked on my keyboard.
>
> On Tuesday, April 16, 2019 at 6:54:16 PM UTC-4, Ryan Winchester wrote:
>>
>> Yeah, sorry
>>
>> value |> (&{:ok, &1}).()
>>
>> On April 16, 2019 at 3:51:28 PM, Ryan Winchester (he...@ryanwinchester.ca
>> ) wrote:
>>
>> value |> (&{&1}).() |> Tuple.insert_at(0, :ok)
>>
>> On April 16, 2019 at 3:47:58 PM, t...@scalpel.com (t...@scalpel.com )
>> wrote:
>>
>> Fair enough, I know when to give up on a losing battle.
>>
>> Would you consider an alternative like Tuple.wrap/1. It would work
>> exactly like List.wrap/1 but doesn't carry the baggage that "error" and
>> "ok" would have. This way I could still accomplish the goal of keeping pipe
>> chains clean with something like.
>>
>> value |> Tuple.wrap() |> Tuple.insert_at(0, :ok)
>>
>> Which is a bit wordier but functionally equivalent to the original
>> proposal.
>>
>> On Tuesday, April 16, 2019 at 6:04:55 PM UTC-4, José Valim wrote:
>>>
>>> Hi Tom,
>>>
>>> You don't have to buy the arguments, we can agree to disagree, but they
>>> are still the reason for not adding such functions to Elixir. :)
>>>
>>> I also agree with is_even and is_odd being similar convenience functions
>>> but they do have a rationale. They were added before defguard existed. At
>>> the time, writing guards was a bit more bureaucratic. But if is_odd/is_even
>>> were proposed today, they would most likely have been rejected as well.
>>>
>>> Elixir already has a perfectly fine syntax via curly brackets for
>>> creating ok and error tuples, that also works on matching, so my
>>> recommendation is still to build an extra vocabulary in your app or as a
>>> separate library.
>>>
>>> *José Valim*
>>> www.plataformatec.com.br
>>> Skype: jv.ptec
>>> Founder and Director of R&D
>>>
>>>
>>> On Tue, Apr 16, 2019 at 11:46 PM <t...@scalpel.com > wrote:
>>>
>>>> I disagree that this should be a library. (I've already done this in my
>>>> app and would be fine extracting it into one though) I don't buy the
>>>> slippery slope argument. The functions are very simple to create and
>>>> maintain, and it's not like the Tuple module is overflowing with
>>>> complexity. We have things like 'is_even' and 'is_odd' because they are
>>>> common to work with. :ok and :error are insanely common in elixir
>>>> codebases. Why not add convenience methods?
>>>>
>>>> On Tuesday, April 16, 2019 at 5:22:38 PM UTC-4, José Valim wrote:
>>>>>
>>>>> Hi Tom, thanks for the proposal.
>>>>>
>>>>> As OvermindDL1 already hinted, this can lead to a slippery slope where
>>>>> we need to add bang variants, question mark variants, ok/1/2/3/4 to deal
>>>>> with arities and so on. I would suggest building this vocabulary as
>>>>> necessary in your applications or, if you want to share it with the world,
>>>>> it could be a nice library. Hint: the package ok_error seems to be
>>>>> available. :)
>>>>>
>>>>> *José Valim*
>>>>> www.plataformatec.com.br
>>>>> Skype: jv.ptec
>>>>> Founder and Director of R&D
>>>>>
>>>>>
>>>>> On Tue, Apr 16, 2019 at 11:12 PM OvermindDL1 <overm...@gmail.com >
>>>>> wrote:
>>>>>
>>>>>> On Tuesday, April 16, 2019 at 3:04:13 PM UTC-6, t...@scalpel.com
>>>>>> wrote:
>>>>>>>
>>>>>>> It is often the case that you want to wrap the result of an
>>>>>>> operation in an ":ok" or ":error" Tuple. We should add convenience
>>>>>>> wrapper
>>>>>>> functions since this is so common and it cleans up otherwise ugly code.
>>>>>>>
>>>>>>> def ok(value), do: {:ok, value}
>>>>>>> def error(value), do: {:error, value}
>>>>>>>
>>>>>>
>>>>>> This could be quite useful! On the other side it would be useful to
>>>>>> add functions like these as well:
>>>>>>
>>>>>> def ok!({:ok, value}), do: value
>>>>>>
>>>>>> def ok?({:ok, _value}), do: true
>>>>>> def ok?(_), do: false
>>>>>>
>>>>>> And so forth for error as well. They are not really useful on their
>>>>>> own because matching is better, but for use in pipes that would be quite
>>>>>> useful (right now I use the exceptional library, which does similar
>>>>>> things
>>>>>> and more).
>>>>>> --
>>>>>> 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-l...@googlegroups.com .
>>>>>> To view this discussion on the web visit https://groups.google.com/d/
>>>>>> msgid/elixir-lang-core/ 30614530-7e33-4cb8-bffb-
>>>>>> 63c18248d340%40googlegroups. com
>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/30614530-7e33-4cb8-bffb-63c18248d340%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>> For more options, visit https://groups.google.com/d/ optout
>>>>>> <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 elixir-l...@ googlegroups.com .
>>>> To view this discussion on the web visit https://groups.google.com/d/
>>>> msgid/elixir-lang-core/ 0314757d-eff2-4b23-8130-
>>>> a19ee921b254%40googlegroups. com
>>>> <https://groups.google.com/d/msgid/elixir-lang-core/0314757d-eff2-4b23-8130-a19ee921b254%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/ optout
>>>> <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 elixir-l...@googlegroups.com .
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elixir-lang-core/2e7204c7-6d06-49f9-8edc-7c631f75063a%40googlegroups.com
>> <https://groups.google.com/d/msgid/elixir-lang-core/2e7204c7-6d06-49f9-8edc-7c631f75063a%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 elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/721abcf1-0cfd-4824-b54a-ff2aa22487f3%40googlegroups.com
> <https://groups.google.com/d/msgid/elixir-lang-core/721abcf1-0cfd-4824-b54a-ff2aa22487f3%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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4LNegXtcdSQ6cUqSrR9tWWo9RK9fhJ-CudEsa8%2BJNSwfg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
